Re: kernel panic: stack is corrupted in udp4_lib_lookup2

[Stefano Brivio]

On Fri, 4 Jan 2019 12:24:18 -0500
Willem de Bruijn <willemdebruijn.kernel@xxxxxxxxx> wrote:

> On Fri, Jan 4, 2019 at 12:14 PM Stefano Brivio <sbrivio@xxxxxxxxxx> wrote:
> >
> > On Fri, 4 Jan 2019 12:05:04 +0100
> > Dmitry Vyukov <dvyukov@xxxxxxxxxx> wrote:
> >  
> > > On Fri, Jan 4, 2019 at 11:54 AM Stefano Brivio <sbrivio@xxxxxxxxxx> wrote:  
> > > >
> > > > On Fri, 4 Jan 2019 11:32:12 +0100
> > > > Dmitry Vyukov <dvyukov@xxxxxxxxxx> wrote:
> > > >  
> > > > > On Thu, Jan 3, 2019 at 10:54 PM Stefano Brivio <sbrivio@xxxxxxxxxx> wrote:  
> > > > > >
> > > > > > On Thu, 3 Jan 2019 15:15:06 -0600
> > > > > > Willem de Bruijn <willemdebruijn.kernel@xxxxxxxxx> wrote:
> > > > > >  
> > > > > > > syzbot generated stack traces with
> > > > > > >
> > > > > > > [  183.517380]  udpv6_err+0x46/0x60
> > > > > > > [  183.520739]  ? __udp6_lib_err+0x1890/0x1890
> > > > > > > [  183.525054]  gue6_err_proto_handler+0x199/0x280  
> > > > > >
> > > > > > Where? I can't find that in any logs linked from the dashboard at
> > > > > > https://syzkaller.appspot.com/bug?extid=4ad25edc7a33e4ab91e0 :(  
> > > > >
> > > > > Stefano, there are these 4 bugs reported that have similarly looking
> > > > > reproducers involving udp sockets and that crash modes that looks like
> > > > > stack corruption/overflow:
> > > > >
> > > > > https://syzkaller.appspot.com/bug?extid=14005fa30c9a07192934
> > > > > https://syzkaller.appspot.com/bug?extid=d14090007dc9ba5fa9b7
> > > > > https://syzkaller.appspot.com/bug?extid=137ed32ec9a6d5b0d5fe
> > > > > https://syzkaller.appspot.com/bug?id=d5bc3e0c66d200d72216ab343a67c4327e4a3452
> > > > >
> > > > > Are these the same bug as this?  
> > > >
> > > > Judging from the reproducers for the first three, they seem to be.  
> > >
> > > OK, then I will mark them as dups of this one.  
> >
> > syzbot just finished the tests I requested and couldn't reproduce the
> > first three issues with the fix I posted (fou6: Prevent unbounded
> > recursion in GUE error handler).  
> 
> Thanks for preparing the fixes so quickly, Stefano.
> 
> I also noticed one trace that seemingly goes through an ip6erspan
> tunnel as well as gue6.
> 
> [  760.618683]  ? __udp6_lib_err+0xcb/0x640
> [  760.622716]  ? udplitev6_err+0x46/0x60
> [  760.626573]  ? gue6_err+0x105/0x270
> [  760.630170]  ? udp_lib_close+0x20/0x20
> [  760.634027]  ? ip6erspan_tunnel_xmit+0xdc0/0xdc0
> 
> Without knowing the err_handler code too well: is it possible that
> packets with an intermediate IPIP or other tunnel still bypass the
> checks (which check for strictly UDP in GUE)?

Yes, I also noticed that, and concluded it's not an issue, but thanks
for pointing that out.

Recursion can't happen there because other handlers don't forward the
exception to the exception handler of the inner layer. For ERSPAN, e.g.,
see ip6gre_err(): it "simply" looks up the tunnel and calls
ip6_update_pmtu() and ip6_redirect().

For FoU and GUE this is not possible as we don't maintain enough state
to be reasonably sure the exception is legitimate.

-- 
Stefano