kernel/drivers/usb/core/hub.c, branch linux-5.1.y

usb: Handle USB3 remote wakeup for LPM enabled devices correctly

2019-07-26T07:13:07Z

commit e244c4699f859cf7149b0781b1894c7996a8a1df upstream. With Link Power Management (LPM) enabled USB3 links transition to low power U1/U2 link states from U0 state automatically. Current hub code detects USB3 remote wakeups by checking if the software state still shows suspended, but the link has transitioned from suspended U3 to enabled U0 state. As it takes some time before the hub thread reads the port link state after a USB3 wake notification, the link may have transitioned from U0 to U1/U2, and wake is not detected by hub code. Fix this by handling U1/U2 states in the same way as U0 in USB3 wakeup handling This patch should be added to stable kernels since 4.13 where LPM was kept enabled during suspend/resume Cc: # v4.13+ Signed-off-by: Lee, Chiasheng Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman

USB: core: Don't unbind interfaces following device reset failure

2019-05-31T13:43:30Z

[ Upstream commit 381419fa720060ba48b7bbc483be787d5b1dca6f ] The SCSI core does not like to have devices or hosts unregistered while error recovery is in progress. Trying to do so can lead to self-deadlock: Part of the removal code tries to obtain a lock already held by the error handler. This can cause problems for the usb-storage and uas drivers, because their error handler routines perform a USB reset, and if the reset fails then the USB core automatically goes on to unbind all drivers from the device's interfaces -- all while still in the context of the SCSI error handler. As it turns out, practically all the scenarios leading to a USB reset failure end up causing a device disconnect (the main error pathway in usb_reset_and_verify_device(), at the end of the routine, calls hub_port_logical_disconnect() before returning). As a result, the hub_wq thread will soon become aware of the problem and will unbind all the device's drivers in its own context, not in the error-handler's context. This means that usb_reset_device() does not need to call usb_unbind_and_rebind_marked_interfaces() in cases where usb_reset_and_verify_device() has returned an error, because hub_wq will take care of everything anyway. This particular problem was observed in somewhat artificial circumstances, by using usbfs to tell a hub to power-down a port connected to a USB-3 mass storage device using the UAS protocol. With the port turned off, the currently executing command timed out and the error handler started running. The USB reset naturally failed, because the hub port was off, and the error handler deadlocked as described above. Not carrying out the call to usb_unbind_and_rebind_marked_interfaces() fixes this issue. Signed-off-by: Alan Stern Reported-by: Kento Kobayashi Tested-by: Kento Kobayashi CC: Bart Van Assche CC: Martin K. Petersen CC: Jacky Cao Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

usb: handle warm-reset port requests on hub resume

2019-02-08T09:21:22Z

On plug-in of my USB-C device, its USB_SS_PORT_LS_SS_INACTIVE link state bit is set. Greping all the kernel for this bit shows that the port status requests a warm-reset this way. This just happens, if its the only device on the root hub, the hub therefore resumes and the HCDs status_urb isn't yet available. If a warm-reset request is detected, this sets the hubs event_bits, which will prevent any auto-suspend and allows the hubs workqueue to warm-reset the port later in port_event. Signed-off-by: Jan-Marek Glogowski Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman

USB: Consolidate LPM checks to avoid enabling LPM twice

2019-01-18T09:02:56Z

USB Bluetooth controller QCA ROME (0cf3:e007) sometimes stops working after S3: [ 165.110742] Bluetooth: hci0: using NVM file: qca/nvm_usb_00000302.bin [ 168.432065] Bluetooth: hci0: Failed to send body at 4 of 1953 (-110) After some experiments, I found that disabling LPM can workaround the issue. On some platforms, the USB power is cut during S3, so the driver uses reset-resume to resume the device. During port resume, LPM gets enabled twice, by usb_reset_and_verify_device() and usb_port_resume(). Consolidate all checks into new LPM helpers to make sure LPM only gets enabled once. Fixes: de68bab4fa96 ("usb: Don't enable USB 2.0 Link PM by default.”) Signed-off-by: Kai-Heng Feng Cc: stable # after much soaking Signed-off-by: Greg Kroah-Hartman

USB: Add new USB LPM helpers

2019-01-18T09:02:56Z

Use new helpers to make LPM enabling/disabling more clear. This is a preparation to subsequent patch. Signed-off-by: Kai-Heng Feng Cc: stable # after much soaking Signed-off-by: Greg Kroah-Hartman

usb: hub: add retry routine after intr URB submit error

2019-01-18T08:58:04Z

The hub sends hot-plug events to the host trough it's interrupt URB. The driver takes care of completing the URB and re-submitting it. Completion errors are handled in the hub_event() work, yet submission errors are ignored, rendering the device unresponsive. All further events are lost. It is fairly hard to find this issue in the wild, since you have to time the USB hot-plug event with the URB submission failure. For instance it could be the system running out of memory or some malfunction in the USB controller driver. Nevertheless, it's pretty reasonable to think it'll happen sometime. One can trigger this issue using eBPF's function override feature (see BCC's inject.py script). This patch adds a retry routine to the event of a submission error. The HUB driver will try to re-submit the URB once every second until it's successful or the HUB is disconnected. As some USB subsystems already take care of this issue, the implementation was inspired from usbhid/hid_core.c's. Signed-off-by: Nicolas Saenz Julienne Reviewed-by: Oliver Neukum Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman

Merge 4.20-rc6 into usb-next

2018-12-10T09:19:08Z

We want the USB fixes in here as well. Signed-off-by: Greg Kroah-Hartman

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: 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: hub: delay hub autosuspend if USB3 port is still link training

2018-12-05T09:12:31Z

When initializing a hub we want to give a USB3 port in link training the same debounce delay time before autosuspening the hub as already trained, connected enabled ports. USB3 ports won't reach the enabled state with "current connect status" and "connect status change" bits set until the USB3 link training finishes. Catching the port in link training (polling) and adding the debounce delay prevents unnecessary failed attempts to autosuspend the hub. Signed-off-by: Mathias Nyman Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman