[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.44L0.1904231126500.1461-100000@iolanthe.rowland.org>
Date: Tue, 23 Apr 2019 11:28:50 -0400 (EDT)
From: Alan Stern <stern@...land.harvard.edu>
To: Andrey Konovalov <andreyknvl@...gle.com>
cc: syzbot <syzbot+2eb9121678bdb36e6d57@...kaller.appspotmail.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Kernel development list <linux-kernel@...r.kernel.org>,
USB list <linux-usb@...r.kernel.org>, <rafael@...nel.org>,
syzkaller-bugs <syzkaller-bugs@...glegroups.com>,
Dmitry Vyukov <dvyukov@...gle.com>
Subject: Re: general protection fault in __dev_printk
On Tue, 23 Apr 2019, Andrey Konovalov wrote:
> > 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.
That's a great suggestion! Here's the next attempt.
Alan Stern
#syz test: https://github.com/google/kasan.git usb-fuzzer
--- a/drivers/usb/misc/yurex.c
+++ b/drivers/usb/misc/yurex.c
@@ -143,8 +143,10 @@ static void yurex_interrupt(struct urb *
/* The device is terminated, clean up */
return;
default:
+#if 0
dev_err(&dev->interface->dev,
"%s - unknown status received: %d\n", __func__, status);
+#endif
goto exit;
}
@@ -178,6 +180,10 @@ static void yurex_interrupt(struct urb *
}
exit:
+ if (!usb_get_intfdata(dev->interface)) {
+ dev_info(&dev->interface->dev, "%s unbound\n", __func__);
+ return;
+ }
retval = usb_submit_urb(dev->urb, GFP_ATOMIC);
if (retval) {
dev_err(&dev->interface->dev, "%s - usb_submit_urb failed: %d\n",
@@ -309,11 +315,15 @@ static void yurex_disconnect(struct usb_
dev = usb_get_intfdata(interface);
usb_set_intfdata(interface, NULL);
+ dev_info(&interface->dev, "%s\n", __func__);
/* give back our minor */
usb_deregister_dev(interface, &yurex_class);
/* prevent more I/O from starting */
+ dev_info(&interface->dev, "Before poison\n");
+ usb_poison_urb(dev->urb);
+ dev_info(&interface->dev, "After poison\n");
mutex_lock(&dev->io_mutex);
dev->interface = NULL;
mutex_unlock(&dev->io_mutex);
Powered by blists - more mailing lists