On Thu, 28 Jul 2016, Greg KH wrote: > On Thu, Jul 28, 2016 at 12:23:01PM -0400, roswest wrote: > > > > Alan, > > > > Hi, I am an engineer at Cisco Systems, and this summer we tasked some > > interns with performing USB fuzzing. One of the interns, Jake Lamberson, > > was able to cause a kernel panic when emulating an HID keyboard because > > the OHCI driver fails to reserve bandwidth for the device. Please see > > the attachment for details. > > > > Thank you, > > Rosie Hall > > > > > Headline: Linux Kernel Panic Over USB with HID Keyboard wMaxPacketSize > > Platforms: Ubuntu > > Versions: Linux Kernel 4.4.0-22-generic > > CVSS Score: 4.7 > > CVSS Vector: AV:L/AC:M/Au:N/C:N/I:N/A:C > > Filed Defects: > > Related Defects: > > CWE Tags: > > Cycle: > > Found by: Jake Lamberson > > > > > > Linux Kernel panics when using an OHCI controller if a USB device reports being > > a generic HID keyboard and reports a wMaxPacketSize of over 4095. The OHCI > > controller driver fails to reserve bandwidth for the device, causing the > > keyboard handler to fail when attaching to the HID. Later, when the device is > > removed, the system crashes due to a null pointer dereference in a linked list > > of endpoint descriptors. The crash can be re-created using a Facedancer and UMAP > > software. Given an appropriately configured Facedancer and UMAP setup, the crash > > can be re-created with: > > sudo board=facedancer21 python3 umap.py -P /dev/serial_device_here -f 03:00:00:E:0046 -l LOG > > > > Note: OHCI is a USB 1.1 controller standard that can be included with devices > > that support either USB 1.1 or 2.0 as their highest USB spec. USB 3.0 devices > > all use xHCI, which implements USB 1.1, 2.0, and 3.0, making them immune to > > this particular bug. > > Do you happen to have a copy of the oops message from the crash to help > let us know where we should be fixing this? Odds are we should just be > catching this in the USB core and not be relying on the host controller > to get it right. Only bits 10..0 of the wMaxPacketSize field contain the maximum packet size; bits 12..11 contain something else (valid only for high-speed periodic endpoints) and bits 15..13 are reserved (see Table 9-13 in the USB-2.0 spec). Furthermore, the value in bits 10..0 is never supposed to be larger than 1024 (or less depending on the speed and the endpoint type). We should check these things in config.c/usb_parse_endpoint(). I will whip up a patch for this shortly. Alan Stern -- 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
