Re: kernel panic: stack is corrupted in udp4_lib_lookup2

[Dmitry Vyukov]

On Fri, Jan 4, 2019 at 6: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).
>
> This should prove they are in fact the same issue.
>
> > > I
> > > guess I can trigger tests also for those by sending a (sharp)syz
> > > test ... e-mail with the patch to the Reported-by: addresses, right?
> >
> > Correct.
> > These should be on LKML, but as you noted you can just add the syzbot
> > email with tag to TO/CC. That email is available in the Reported-by
> > tag (and also shown on the dashboard).
>
> Okay, thanks for confirming.
>
> > > And the three reports you pointed out from the pile of corrupted
> > > reports also seem to match, others look unrelated.
> >
> > I've added these as tests:
> >
> > https://github.com/google/syzkaller/blob/master/pkg/report/testdata/linux/report/341
> > https://github.com/google/syzkaller/blob/master/pkg/report/testdata/linux/report/342
> > https://github.com/google/syzkaller/blob/master/pkg/report/testdata/linux/report/343
> > https://github.com/google/syzkaller/blob/master/pkg/report/testdata/linux/report/344
> >
> > Will try to figure out how to distinguish them from true corrupted
> > reports. Usually when Call Trace does not have any frames, it's a sign
> > of a corrupted report, and in other crashes we see the same report but
> > with a stack trace. But some stack-corruption-related reliably don't
> > have stack traces (not corrupted). But then some other
> > stack-corruption-related crashes do have stack traces, and for these
> > no stack trace again means a corrupted kernel output. Amusingly this
> > is one of the most complex parts of syzkaller.
>
> I'm not sure how complicated that would be, but what about some metric
> based on valid symbol names being reported?

Please elaborate. What do you mean by "valid symbol names"?

Note that corrupted output detection solves 2 problems:
1. Do we think the output is truncated to the point of being not useful?
E.g. sometimes kernel produces just 1 line:

general protection fault: 0000 [#1] PREEMPT SMP KASAN

This is sure a crash, but it's not too useful to report.

2. Do we have any reasons to think we extracted bogus crash identity?
E.g. crash intermixed with output from another thread so that we say
"something-bad in function foo", when in fact function foo come from
output of the second non-crashing thread.