linux/drivers/usb/core, branch v4.20

USB: check usb_get_extra_descriptor for proper size

2018-12-05T20:20:14Z

When reading an extra descriptor, we need to properly check the minimum and maximum size allowed, to prevent from invalid data being sent by a device. Reported-by: Hui Peng Reported-by: Mathias Payer Co-developed-by: Linus Torvalds Signed-off-by: Hui Peng Signed-off-by: Mathias Payer Signed-off-by: Linus Torvalds Cc: stable Signed-off-by: Greg Kroah-Hartman

usb: quirk: add no-LPM quirk on SanDisk Ultra Flair device

2018-12-05T09:37:29Z

Some lower volume SanDisk Ultra Flair in 16GB, which the VID:PID is in 0781:5591, will aggressively request LPM of U1/U2 during runtime, when using this thumb drive as the OS installation key we found the device will generate failure during U1 exit path making it dropped from the USB bus, this causes a corrupted installation in system at the end. i.e., [ 166.918296] hub 2-0:1.0: state 7 ports 7 chg 0000 evt 0004 [ 166.918327] usb usb2-port2: link state change [ 166.918337] usb usb2-port2: do warm reset [ 166.970039] usb usb2-port2: not warm reset yet, waiting 50ms [ 167.022040] usb usb2-port2: not warm reset yet, waiting 200ms [ 167.276043] usb usb2-port2: status 02c0, change 0041, 5.0 Gb/s [ 167.276050] usb 2-2: USB disconnect, device number 2 [ 167.276058] usb 2-2: unregistering device [ 167.276060] usb 2-2: unregistering interface 2-2:1.0 [ 167.276170] xhci_hcd 0000:00:15.0: shutdown urb ffffa3c7cc695cc0 ep1in-bulk [ 167.284055] sd 0:0:0:0: [sda] tag#0 FAILED Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK [ 167.284064] sd 0:0:0:0: [sda] tag#0 CDB: Read(10) 28 00 00 33 04 90 00 01 00 00 ... Analyzed the USB trace in the link layer we realized it is because of the 6-ms timer of tRecoveryConfigurationTimeout which documented on the USB 3.2 Revision 1.0, the section 7.5.10.4.2 of "Exit from Recovery.Configuration"; device initiates U1 exit -> Recovery.Active -> Recovery.Configuration, then the host timer timeout makes the link transits to eSS.Inactive -> Rx.Detect follows by a Warm Reset. Interestingly, the other higher volume of SanDisk Ultra Flair sharing the same VID:PID, such as 64GB, would not request LPM during runtime, it sticks at U0 always, thus disabling LPM does not affect those thumb drives at all. The same odd occures in SanDisk Ultra Fit 16GB, VID:PID in 0781:5583. Signed-off-by: Harry Pan Cc: stable Signed-off-by: Greg Kroah-Hartman

USB: Fix invalid-free bug in port_over_current_notify()

2018-12-05T09:37:29Z

Syzbot and KASAN found the following invalid-free bug in port_over_current_notify(): -------------------------------------------------------------------------- BUG: KASAN: double-free or invalid-free in port_over_current_notify drivers/usb/core/hub.c:5192 [inline] BUG: KASAN: double-free or invalid-free in port_event drivers/usb/core/hub.c:5241 [inline] BUG: KASAN: double-free or invalid-free in hub_event+0xd97/0x4140 drivers/usb/core/hub.c:5384 CPU: 1 PID: 32710 Comm: kworker/1:3 Not tainted 4.20.0-rc3+ #129 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: usb_hub_wq hub_event Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x244/0x39d lib/dump_stack.c:113 print_address_description.cold.7+0x9/0x1ff mm/kasan/report.c:256 kasan_report_invalid_free+0x64/0xa0 mm/kasan/report.c:336 __kasan_slab_free+0x13a/0x150 mm/kasan/kasan.c:501 kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528 __cache_free mm/slab.c:3498 [inline] kfree+0xcf/0x230 mm/slab.c:3817 port_over_current_notify drivers/usb/core/hub.c:5192 [inline] port_event drivers/usb/core/hub.c:5241 [inline] hub_event+0xd97/0x4140 drivers/usb/core/hub.c:5384 process_one_work+0xc90/0x1c40 kernel/workqueue.c:2153 worker_thread+0x17f/0x1390 kernel/workqueue.c:2296 kthread+0x35a/0x440 kernel/kthread.c:246 ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352 -------------------------------------------------------------------------- The problem is caused by use of a static array to store environment-string pointers. When the routine is called by multiple threads concurrently, the pointers from one thread can overwrite those from another. The solution is to use an ordinary automatic array instead of a static array. Signed-off-by: Alan Stern Reported-by: syzbot+98881958e1410ec7e53c@syzkaller.appspotmail.com Cc: stable Signed-off-by: Greg Kroah-Hartman

usb: core: quirks: add RESET_RESUME quirk for Cherry G230 Stream series

2018-11-26T07:09:47Z

Cherry G230 Stream 2.0 (G85-231) and 3.0 (G85-232) need this quirk to function correctly. This fixes a but where double pressing numlock locks up the device completely with need to replug the keyboard. Signed-off-by: Michael Niewöhner Tested-by: Michael Niewöhner Cc: stable Signed-off-by: Greg Kroah-Hartman

usb: core: Fix hub port connection events lost

2018-11-14T22:28:26Z

This will clear the USB_PORT_FEAT_C_CONNECTION bit in case of a hub port reset only if a device is was attached to the hub port before resetting the hub port. Using a Lenovo T480s attached to the ultra dock it was not possible to detect some usb-c devices at the dock usb-c ports because the hub_port_reset code will clear the USB_PORT_FEAT_C_CONNECTION bit after the actual hub port reset. Using this device combo the USB_PORT_FEAT_C_CONNECTION bit was set between the actual hub port reset and the clear of the USB_PORT_FEAT_C_CONNECTION bit. This ends up with clearing the USB_PORT_FEAT_C_CONNECTION bit after the new device was attached such that it was not detected. This patch will not clear the USB_PORT_FEAT_C_CONNECTION bit if there is currently no device attached to the port before the hub port reset. This will avoid clearing the connection bit for new attached devices. Signed-off-by: Dennis Wassenberg Acked-by: Mathias Nyman Cc: stable Signed-off-by: Greg Kroah-Hartman

USB: quirks: Add no-lpm quirk for Raydium touchscreens

2018-11-07T12:23:18Z

Raydium USB touchscreen fails to set config if LPM is enabled: [ 2.030658] usb 1-8: New USB device found, idVendor=2386, idProduct=3119 [ 2.030659] usb 1-8: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 2.030660] usb 1-8: Product: Raydium Touch System [ 2.030661] usb 1-8: Manufacturer: Raydium Corporation [ 7.132209] usb 1-8: can't set config #1, error -110 Same behavior can be observed on 2386:3114. Raydium claims the touchscreen supports LPM under Windows, so I used Microsoft USB Test Tools (MUTT) [1] to check its LPM status. MUTT shows that the LPM doesn't work under Windows, either. So let's just disable LPM for Raydium touchscreens. [1] https://docs.microsoft.com/en-us/windows-hardware/drivers/usbcon/usb-test-tools Signed-off-by: Kai-Heng Feng Cc: stable Signed-off-by: Greg Kroah-Hartman

usb: quirks: Add delay-init quirk for Corsair K70 LUX RGB

2018-11-07T12:23:18Z

Following on from this patch: https://lkml.org/lkml/2017/11/3/516, Corsair K70 LUX RGB keyboards also require the DELAY_INIT quirk to start correctly at boot. Dmesg output: usb 1-6: string descriptor 0 read error: -110 usb 1-6: New USB device found, idVendor=1b1c, idProduct=1b33 usb 1-6: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 1-6: can't set config #1, error -110 Signed-off-by: Emmanuel Pescosta Cc: stable Signed-off-by: Greg Kroah-Hartman

USB: Wait for extra delay time after USB_PORT_FEAT_RESET for quirky hub

2018-11-07T12:23:18Z

Devices connected under Terminus Technology Inc. Hub (1a40:0101) may fail to work after the system resumes from suspend: [ 206.063325] usb 3-2.4: reset full-speed USB device number 4 using xhci_hcd [ 206.143691] usb 3-2.4: device descriptor read/64, error -32 [ 206.351671] usb 3-2.4: device descriptor read/64, error -32 Info for this hub: T: Bus=03 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 2 Spd=480 MxCh= 4 D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=1a40 ProdID=0101 Rev=01.11 S: Product=USB 2.0 Hub C: #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub Some expirements indicate that the USB devices connected to the hub are innocent, it's the hub itself is to blame. The hub needs extra delay time after it resets its port. Hence wait for extra delay, if the device is connected to this quirky hub. Signed-off-by: Kai-Heng Feng Cc: stable Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman

Merge tag 'usb-4.20-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb

2018-10-26T15:14:13Z

Pull USB/PHY updates from Greg KH: "Here is the big USB/PHY driver patches for 4.20-rc1 Lots of USB changes in here, primarily in these areas: - typec updates and new drivers - new PHY drivers - dwc2 driver updates and additions (this old core keeps getting added to new devices.) - usbtmc major update based on the industry group coming together and working to add new features and performance to the driver. - USB gadget additions for new features - USB gadget configfs updates - chipidea driver updates - other USB gadget updates - USB serial driver updates - renesas driver updates - xhci driver updates - other tiny USB driver updates All of these have been in linux-next for a while with no reported issues" * tag 'usb-4.20-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (229 commits) usb: phy: ab8500: silence some uninitialized variable warnings usb: xhci: tegra: Add genpd support usb: xhci: tegra: Power-off power-domains on removal usbip:vudc: BUG kmalloc-2048 (Not tainted): Poison overwritten usbip: tools: fix atoi() on non-null terminated string USB: misc: appledisplay: fix backlight update_status return code phy: phy-pxa-usb: add a new driver usb: host: add DT bindings for faraday fotg2 usb: host: ohci-at91: fix request of irq for optional gpio usb/early: remove set but not used variable 'remain_length' usb: typec: Fix copy/paste on typec_set_vconn_role() kerneldoc usb: typec: tcpm: Report back negotiated PPS voltage and current USB: core: remove set but not used variable 'udev' usb: core: fix memory leak on port_dev_path allocation USB: net2280: Remove ->disconnect() callback from net2280_pullup() usb: dwc2: disable power_down on rockchip devices usb: gadget: udc: renesas_usb3: add support for r8a77990 dt-bindings: usb: renesas_usb3: add bindings for r8a77990 usb: gadget: udc: renesas_usb3: Add r8a774a1 support USB: serial: cypress_m8: remove set but not used variable 'iflag' ...

Merge branch 'siginfo-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace

2018-10-24T10:22:39Z

Pull siginfo updates from Eric Biederman: "I have been slowly sorting out siginfo and this is the culmination of that work. The primary result is in several ways the signal infrastructure has been made less error prone. The code has been updated so that manually specifying SEND_SIG_FORCED is never necessary. The conversion to the new siginfo sending functions is now complete, which makes it difficult to send a signal without filling in the proper siginfo fields. At the tail end of the patchset comes the optimization of decreasing the size of struct siginfo in the kernel from 128 bytes to about 48 bytes on 64bit. The fundamental observation that enables this is by definition none of the known ways to use struct siginfo uses the extra bytes. This comes at the cost of a small user space observable difference. For the rare case of siginfo being injected into the kernel only what can be copied into kernel_siginfo is delivered to the destination, the rest of the bytes are set to 0. For cases where the signal and the si_code are known this is safe, because we know those bytes are not used. For cases where the signal and si_code combination is unknown the bits that won't fit into struct kernel_siginfo are tested to verify they are zero, and the send fails if they are not. I made an extensive search through userspace code and I could not find anything that would break because of the above change. If it turns out I did break something it will take just the revert of a single change to restore kernel_siginfo to the same size as userspace siginfo. Testing did reveal dependencies on preferring the signo passed to sigqueueinfo over si->signo, so bit the bullet and added the complexity necessary to handle that case. Testing also revealed bad things can happen if a negative signal number is passed into the system calls. Something no sane application will do but something a malicious program or a fuzzer might do. So I have fixed the code that performs the bounds checks to ensure negative signal numbers are handled" * 'siginfo-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace: (80 commits) signal: Guard against negative signal numbers in copy_siginfo_from_user32 signal: Guard against negative signal numbers in copy_siginfo_from_user signal: In sigqueueinfo prefer sig not si_signo signal: Use a smaller struct siginfo in the kernel signal: Distinguish between kernel_siginfo and siginfo signal: Introduce copy_siginfo_from_user and use it's return value signal: Remove the need for __ARCH_SI_PREABLE_SIZE and SI_PAD_SIZE signal: Fail sigqueueinfo if si_signo != sig signal/sparc: Move EMT_TAGOVF into the generic siginfo.h signal/unicore32: Use force_sig_fault where appropriate signal/unicore32: Generate siginfo in ucs32_notify_die signal/unicore32: Use send_sig_fault where appropriate signal/arc: Use force_sig_fault where appropriate signal/arc: Push siginfo generation into unhandled_exception signal/ia64: Use force_sig_fault where appropriate signal/ia64: Use the force_sig(SIGSEGV,...) in ia64_rt_sigreturn signal/ia64: Use the generic force_sigsegv in setup_frame signal/arm/kvm: Use send_sig_mceerr signal/arm: Use send_sig_fault where appropriate signal/arm: Use force_sig_fault where appropriate ...