lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 9 Nov 2017 13:19:16 +0100
From:   Andrey Konovalov <andreyknvl@...gle.com>
To:     Alan Stern <stern@...land.harvard.edu>
Cc:     Greg KH <gregkh@...uxfoundation.org>,
        syzbot 
        <bot+50d191d34989b5aa28596b0a2cb20c96f3ca4650@...kaller.appspotmail.com>,
        Felipe Balbi <felipe.balbi@...ux.intel.com>,
        krinkin.m.u@...il.com, LKML <linux-kernel@...r.kernel.org>,
        USB list <linux-usb@...r.kernel.org>,
        syzkaller-bugs@...glegroups.com, Takashi Iwai <tiwai@...e.de>,
        vskrishn@...eaurora.org
Subject: Re: WARNING in usb_submit_urb

On Tue, Nov 7, 2017 at 6:58 PM, Alan Stern <stern@...land.harvard.edu> 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?

This isn't the "BOGUS urb xfer" warning, this is "BOGUS urb flags". So
2 means the URB_ISO_ASAP flag, which is passed in urb->transfer_flags
but not allowed. And as far as I understand, it gets set because uurb
(which is passed from user space) has USBDEVFS_URB_ISO_ASAP flag set
when passed to proc_do_submiturb().

>
> Alan Stern
>

Powered by blists - more mailing lists