Re: kernel panic: stack is corrupted in udp4_lib_lookup2

From: Stefano Brivio
Date: Thu Jan 03 2019 - 15:00:28 EST


Hi Willem,

On Thu, 3 Jan 2019 13:41:43 -0600
Willem de Bruijn <willemdebruijn.kernel@xxxxxxxxx> wrote:

> On Thu, Jan 3, 2019 at 1:39 PM Willem de Bruijn
> <willemdebruijn.kernel@xxxxxxxxx> wrote:
> >
> > On Thu, Jan 3, 2019 at 7:07 AM syzbot
> > <syzbot+4ad25edc7a33e4ab91e0@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
> > >
> > > Hello,
> > >
> > > syzbot found the following crash on:
> > >
> > > HEAD commit: 195303136f19 Merge tag 'kconfig-v4.21-2' of git://git.kern..
> > > git tree: upstream
> > > console output: https://syzkaller.appspot.com/x/log.txt?x=12245d8f400000
> > > kernel config: https://syzkaller.appspot.com/x/.config?x=5e7dc790609552d7
> > > dashboard link: https://syzkaller.appspot.com/bug?extid=4ad25edc7a33e4ab91e0
> > > compiler: gcc (GCC) 8.0.1 20180413 (experimental)
> > >
> > > Unfortunately, I don't have any reproducer for this crash yet.
> > >
> > > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > > Reported-by: syzbot+4ad25edc7a33e4ab91e0@xxxxxxxxxxxxxxxxxxxxxxxxx
> > >
> > > protocol 88fb is buggy, dev hsr_slave_1
> > > protocol 88fb is buggy, dev hsr_slave_0
> > > protocol 88fb is buggy, dev hsr_slave_1
> > > FAT-fs (loop0): invalid media value (0x00)
> > > FAT-fs (loop0): Can't find a valid FAT filesystem
> > > Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in:
> >
> > This sounds similar to the stack corruption fixed recently in commit
> > e7cc082455cb ("udp: Support for error handlers of tunnels ...").
> >
> > That fix is for ipv4 gue_err(). ipv6 gue6_err() probably needs the same.
>
> Correction. The fix is 11789039da ("fou: prevent unbounded recursion
> in GUE error handler")

Yes, I looked into this, the fix for that issue is on the tree tested by
syzbot, and I think this is unrelated, also because KASan should say
something before we hit that.

By the way, do you happen to know if I objects from kernels tested by
syzbot are stored anywhere? It would be helpful to know for sure what's
at udp4_lib_lookup2+0x7ea.

--
Stefano