[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACT4Y+a_0grrUjrovW=0=0UPkH3pE_HpncDc3uBzwR_YtDURPA@mail.gmail.com>
Date: Wed, 8 Nov 2017 08:59:15 +0100
From: Dmitry Vyukov <dvyukov@...gle.com>
To: Herbert Xu <herbert@...dor.apana.org.au>
Cc: syzbot
<bot+413384116f7f7dab7903d54c53fc4af6a4441965@...kaller.appspotmail.com>,
David Miller <davem@...emloft.net>,
LKML <linux-kernel@...r.kernel.org>,
netdev <netdev@...r.kernel.org>,
Steffen Klassert <steffen.klassert@...unet.com>,
syzkaller-bugs@...glegroups.com
Subject: Re: kernel BUG at net/key/af_key.c:LINE!
On Wed, Nov 8, 2017 at 8:47 AM, Herbert Xu <herbert@...dor.apana.org.au> wrote:
> On Tue, Oct 24, 2017 at 05:10:06PM +0200, Dmitry Vyukov wrote:
>> On Tue, Oct 24, 2017 at 5:08 PM, syzbot
>> <bot+413384116f7f7dab7903d54c53fc4af6a4441965@...kaller.appspotmail.com>
>> wrote:
>> > Hello,
>> >
>> > syzkaller hit the following crash on
>> > 02a2b05395dde2f49e7777b67b51a5fbc6606943
>> > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master
>> > compiler: gcc (GCC) 7.1.1 20170620
>> > .config is attached
>> > Raw console output is attached.
>> > C reproducer is attached
>> > syzkaller reproducer is attached. See https://goo.gl/kgGztJ
>> > for information about syzkaller reproducers
>>
>> This also happened on more recent commits, including net-next
>> 833e0e2f24fd0525090878f71e129a8a4cb8bf78 (Oct 10) with similar
>> signature:
>
> Unfortunately I cannot reproduce the crash with your reproducer.
> Does it always crash for you?
>
>> ------------[ cut here ]------------
>> kernel BUG at net/key/af_key.c:2068!
>> invalid opcode: 0000 [#1] SMP KASAN
>> Dumping ftrace buffer:
>> (ftrace buffer empty)
>> Modules linked in:
>> CPU: 1 PID: 11011 Comm: syz-executor1 Not tainted 4.14.0-rc4+ #80
>> Hardware name: Google Google Compute Engine/Google Compute Engine,
>> BIOS Google 01/01/2011
>> task: ffff8801d4ecc1c0 task.stack: ffff8801c13f8000
>> RIP: 0010:pfkey_xfrm_policy2msg+0x209c/0x22b0 net/key/af_key.c:2068
>
> This shows that you have a xfrm policy that has a bogus family
> field in your policy database. But it gives no clue as to how
> it got there.
Just triggered it within a second.
Are you using the provided config?
Also the repro needs to be compiled with -m32 (but it does not compile
without it due to missing __NR_mmap2, so I guess you passed -m32).
Powered by blists - more mailing lists