talos-obmc-linux/drivers/usb/core, branch dev-4.13

USB: Add delay-init quirk for Corsair K70 LUX keyboards

2017-11-21T09:24:34+00:00

commit a0fea6027f19c62727315aba1a7fae75a9caa842 upstream. Without this patch, K70 LUX keyboards don't work, saying usb 3-3: unable to read config index 0 descriptor/all usb 3-3: can't read configurations, error -110 usb usb3-port3: unable to enumerate USB device Signed-off-by: Bernhard Rosenkraenzer Signed-off-by: Greg Kroah-Hartman

USB: usbfs: compute urb->actual_length for isochronous

2017-11-21T09:24:34+00:00

commit 2ef47001b3ee3ded579b7532ebdcf8680e4d8c54 upstream. The USB kerneldoc says that the actual_length field "is read in non-iso completion functions", but the usbfs driver uses it for all URB types in processcompl(). Since not all of the host controller drivers set actual_length for isochronous URBs, programs using usbfs with some host controllers don't work properly. For example, Minas reports that a USB camera controlled by libusb doesn't work properly with a dwc2 controller. It doesn't seem worthwhile to change the HCDs and the documentation, since the in-kernel USB class drivers evidently don't rely on actual_length for isochronous transfers. The easiest solution is for usbfs to calculate the actual_length value for itself, by adding up the lengths of the individual packets in an isochronous transfer. Signed-off-by: Alan Stern CC: Minas Harutyunyan Reported-and-tested-by: wlf Signed-off-by: Greg Kroah-Hartman

usb: hub: Allow reset retry for USB2 devices on connect bounce

2017-10-27T08:39:08+00:00

commit 1ac7db63333db1eeff901bfd6bbcd502b4634fa4 upstream. If the connect status change is set during reset signaling, but the status remains connected just retry port reset. This solves an issue with connecting a 90W HP Thunderbolt 3 dock with a Lenovo Carbon x1 (5th generation) which causes a 30min loop of a high speed device being re-discovererd before usb ports starts working. [...] [ 389.023845] usb 3-1: new high-speed USB device number 55 using xhci_hcd [ 389.491841] usb 3-1: new high-speed USB device number 56 using xhci_hcd [ 389.959928] usb 3-1: new high-speed USB device number 57 using xhci_hcd [...] This is caused by a high speed device that doesn't successfully go to the enabled state after the second port reset. Instead the connection bounces (connected, with connect status change), bailing out completely from enumeration just to restart from scratch. Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1716332 Signed-off-by: Mathias Nyman Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman

usb: quirks: add quirk for WORLDE MINI MIDI keyboard

2017-10-27T08:39:08+00:00

commit 2811501e6d8f5747d08f8e25b9ecf472d0dc4c7d upstream. This keyboard doesn't implement Get String descriptors properly even though string indexes are valid. What happens is that when requesting for the String descriptor, the device disconnects and reconnects. Without this quirk, this loop will continue forever. Cc: Alan Stern Reported-by: Владимир Мартьянов Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman

USB: core: fix out-of-bounds access bug in usb_get_bos_descriptor()

2017-10-27T08:39:08+00:00

commit 1c0edc3633b56000e18d82fc241e3995ca18a69e upstream. Andrey used the syzkaller fuzzer to find an out-of-bounds memory access in usb_get_bos_descriptor(). The code wasn't checking that the next usb_dev_cap_header structure could fit into the remaining buffer space. This patch fixes the error and also reduces the bNumDeviceCaps field in the header to match the actual number of capabilities found, in cases where there are fewer than expected. Reported-by: Andrey Konovalov Signed-off-by: Alan Stern Tested-by: Andrey Konovalov Signed-off-by: Greg Kroah-Hartman

USB: devio: Revert "USB: devio: Don't corrupt user memory"

2017-10-27T08:39:08+00:00

commit 845d584f41eac3475c21e4a7d5e88d0f6e410cf7 upstream. Taking the uurb->buffer_length userspace passes in as a maximum for the actual urbs transfer_buffer_length causes 2 serious issues: 1) It breaks isochronous support for all userspace apps using libusb, as existing libusb versions pass in 0 for uurb->buffer_length, relying on the kernel using the lenghts of the usbdevfs_iso_packet_desc descriptors passed in added together as buffer length. This for example causes redirection of USB audio and Webcam's into virtual machines using qemu-kvm to no longer work. This is a userspace ABI break and as such must be reverted. Note that the original commit does not protect other users / the kernels memory, it only stops the userspace process making the call from shooting itself in the foot. 2) It may cause the kernel to program host controllers to DMA over random memory. Just as the devio code used to only look at the iso_packet_desc lenghts, the host drivers do the same, relying on the submitter of the urbs to make sure the entire buffer is large enough and not checking transfer_buffer_length. But the "USB: devio: Don't corrupt user memory" commit now takes the userspace provided uurb->buffer_length for the buffer-size while copying over the user-provided iso_packet_desc lengths 1:1, allowing the user to specify a small buffer size while programming the host controller to dma a lot more data. (Atleast the ohci, uhci, xhci and fhci drivers do not check transfer_buffer_length for isoc transfers.) This reverts commit fa1ed74eb1c2 ("USB: devio: Don't corrupt user memory") fixing both these issues. Cc: Dan Carpenter Signed-off-by: Hans de Goede Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman

USB: fix out-of-bounds in usb_set_configuration

2017-10-12T09:56:10+00:00

commit bd7a3fe770ebd8391d1c7d072ff88e9e76d063eb upstream. Andrey Konovalov reported a possible out-of-bounds problem for a USB interface association descriptor. He writes: It seems there's no proper size check of a USB_DT_INTERFACE_ASSOCIATION descriptor. It's only checked that the size is >= 2 in usb_parse_configuration(), so find_iad() might do out-of-bounds access to intf_assoc->bInterfaceCount. And he's right, we don't check for crazy descriptors of this type very well, so resolve this problem. Yet another issue found by syzkaller... Reported-by: Andrey Konovalov Tested-by: Andrey Konovalov Signed-off-by: Greg Kroah-Hartman

usb: Increase quirk delay for USB devices

2017-10-12T09:56:10+00:00

commit b2a542bbb3081dbd64acc8929c140d196664c406 upstream. Commit e0429362ab15 ("usb: Add device quirk for Logitech HD Pro Webcams C920 and C930e") introduced quirk to workaround an issue with some Logitech webcams. The workaround is introducing delay for some USB operations. According to our testing, delay introduced by original commit is not long enough and in rare cases we still see issues described by the aforementioned commit. This patch increases delays introduced by original commit. Having this patch applied we do not see those problems anymore. Signed-off-by: Dmitry Fleytman Signed-off-by: Greg Kroah-Hartman

USB: core: harden cdc_parse_cdc_header

2017-10-12T09:56:10+00:00

commit 2e1c42391ff2556387b3cb6308b24f6f65619feb upstream. Andrey Konovalov reported a possible out-of-bounds problem for the cdc_parse_cdc_header function. He writes: It looks like cdc_parse_cdc_header() doesn't validate buflen before accessing buffer[1], buffer[2] and so on. The only check present is while (buflen > 0). So fix this issue up by properly validating the buffer length matches what the descriptor says it is. Reported-by: Andrey Konovalov Tested-by: Andrey Konovalov Signed-off-by: Greg Kroah-Hartman

USB: devio: Don't corrupt user memory

2017-10-12T09:56:09+00:00

commit fa1ed74eb1c233be6131ec92df21ab46499a15b6 upstream. The user buffer has "uurb->buffer_length" bytes. If the kernel has more information than that, we should truncate it instead of writing past the end of the user's buffer. I added a WARN_ONCE() to help the user debug the issue. Reported-by: Alan Stern Signed-off-by: Dan Carpenter Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman