On Tue, Nov 7, 2017 at 6:58 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > On Tue, 7 Nov 2017, Greg KH wrote: > >> On Tue, Nov 07, 2017 at 08:11:13AM -0800, syzbot wrote: >> > Hello, >> > >> > syzkaller hit the following crash on >> > 36ef71cae353f88fd6e095e2aaa3e5953af1685d >> > git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master >> > compiler: gcc (GCC) 7.1.1 20170620 >> > .config is attached >> > Raw console output is attached. >> > C reproducer is attached >> > syzkaller reproducer is attached. See https://goo.gl/kgGztJ >> > for information about syzkaller reproducers >> >> This is not a crash, you are doing a panic-on-warning, and you send >> invalid data to the kernel and it warned about it properly and kept on >> working :) >> >> Perhaps maybe not a full WARN_ON() is to be done here? > > I don't understand how this could have happened. The raw log explains > the problem: > >> [ 15.138822] usb usb1: BOGUS urb flags, 2 --> 0 >> [ 15.139498] ------------[ cut here ]------------ >> [ 15.139955] WARNING: CPU: 3 PID: 2986 at drivers/usb/core/urb.c:498 usb_submit_urb+0xeb9/0x10f0 > ... >> [ 15.150280] RIP: 0010:usb_submit_urb+0xeb9/0x10f0 > ... >> [ 15.155166] proc_do_submiturb+0x1f53/0x3860 > > The "2 --> 0" means that proc_do_submiturb() tried to submit a control > URB (2 = PIPE_CONTROL) to an isochronous endpoint (0 = PIPE_ISOCHRONOUS). > But right near the start of the routine we have: > > switch (uurb->type) { > case USBDEVFS_URB_TYPE_CONTROL: > if (!usb_endpoint_xfer_control(&ep->desc)) > return -EINVAL; > > So how was the warning triggered? I don't know what happened there, but bot provided a repro for this. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
