From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1041797AbdDUSZp (ORCPT ); Fri, 21 Apr 2017 14:25:45 -0400 Received: from mail-oi0-f50.google.com ([209.85.218.50]:33118 "EHLO mail-oi0-f50.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1041324AbdDUSZh (ORCPT ); Fri, 21 Apr 2017 14:25:37 -0400 Subject: Re: net: heap out-of-bounds in fib6_clean_node/rt6_fill_node/fib6_age/fib6_prune_clone To: Eric Dumazet References: <580392d8-fa33-67bb-c5d6-27d262f1646a@cumulusnetworks.com> <1dad955e-28c1-3f02-8876-90cce4a7d1f8@cumulusnetworks.com> <623b6343-14f4-945d-a1bd-c9971b9566c2@cumulusnetworks.com> <1492793238.6453.30.camel@edumazet-glaptop3.roam.corp.google.com> Cc: Andrey Konovalov , Dmitry Vyukov , Cong Wang , Mahesh Bandewar , Eric Dumazet , David Miller , Alexey Kuznetsov , James Morris , Hideaki YOSHIFUJI , Patrick McHardy , netdev , LKML , syzkaller From: David Ahern Message-ID: <75e4e5bb-7ce9-9317-4aca-8be41a8161d7@cumulusnetworks.com> Date: Fri, 21 Apr 2017 12:25:33 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <1492793238.6453.30.camel@edumazet-glaptop3.roam.corp.google.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 4/21/17 10:47 AM, Eric Dumazet wrote: > On Fri, 2017-04-21 at 08:27 -0600, David Ahern wrote: >> On 4/20/17 10:09 AM, Andrey Konovalov wrote: >>> On Thu, Apr 20, 2017 at 5:39 PM, Andrey Konovalov wrote: >>>> On Thu, Apr 20, 2017 at 5:35 PM, David Ahern wrote: >>>>> On 4/20/17 9:28 AM, Andrey Konovalov wrote: >>>>>> This one seems to be much closer to what Dmitry reported intially. >>>>> does not repro here; I ran in a loop and nothing. >>> Here's strace log, maybe it'll help figuring out why it doesn't reproduce: >> >> reproduced. working on it. > > Thanks guys for working on this ;) > Reliable reproducer is the key. I see what's going on - why the WARN_ON is hit; just looking for the right fix.