Re: general protection fault in __dev_printk

[Andrey Konovalov]

On Mon, Apr 22, 2019 at 7:53 PM Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote:
>
> On Thu, 18 Apr 2019, syzbot wrote:
>
> > syzbot has found a reproducer for the following crash on:
> >
> > HEAD commit:    d34f9519 usb-fuzzer: main usb gadget fuzzer driver
> > git tree:       https://github.com/google/kasan/tree/usb-fuzzer
> > console output: https://syzkaller.appspot.com/x/log.txt?x=10adfe6b200000
> > kernel config:  https://syzkaller.appspot.com/x/.config?x=c73d1bb5aeaeae20
> > dashboard link: https://syzkaller.appspot.com/bug?extid=2eb9121678bdb36e6d57
> > compiler:       gcc (GCC) 9.0.0 20181231 (experimental)
> > syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=145cb7e3200000
> > C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=17f8bd2d200000
> >
> > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > Reported-by: syzbot+2eb9121678bdb36e6d57@xxxxxxxxxxxxxxxxxxxxxxxxx
> >
> > yurex 1-1:0.150: yurex_interrupt - unknown status received: -71
> > usb 1-1: USB disconnect, device number 112
> > yurex 1-1:0.150: yurex_interrupt - unknown status received: -71
> > kasan: CONFIG_KASAN_INLINE enabled
> > kasan: GPF could be caused by NULL-ptr deref or user memory access
> > general protection fault: 0000 [#1] SMP KASAN PTI
>
> Andrey:
>
> This original bug report included a "USB disconnect" line, as shown
> above.  The newer results, for runs with my patches added, do not.  At
> least, if such a line was present, it didn't show up in the console
> output files -- the most recent one contains nothing but repeats of
> that "yurex_interrupt - unknown status received: -71" line, although
> for devices on multiple buses.
>
> Is there any way to get more information about what's happening, such
> as a complete kernel log?

It should be possible to provide the full log for the result of the
"syz test" command. I'll talk to Dmitry about this when he's back from
vacation next week.

> And perhaps to run the test with just a
> single dummy-hcd bus instead of 6?

Hm, it might be possible to implement overriding of syz-execprog flags
and provide them via "syz test". It's not implemented right now
though.

Running the reproducer manually is the most flexible way to make
changes to the way it's ran or to make changes to the environment. In
this case I haven't managed to reproduce the hang manually though :(

I see two ways to deal with this right now:

1. Submit your fix (it fixes the original issue for me) and wait until
it gets into the usb-fuzzer tree. Then maybe syzbot will report the
hang and provide a better reproducer.

2. Change the testing patch to also suppress those "yurex_interrupt -
unknown status received: -71" messages and rerun the "syz test"
command. Hopefully then syzbot will provide the full kernel log.

>
> At this point, I suspect the original general protection fault in
> the yurex driver has been fixed, but something else in dummy-hcd may be
> causing the rcu-detected stalls.
>
> Alan Stern
>