cbcvebase.
CVE-2024-40927
published 2024-07-12

CVE-2024-40927: In the Linux kernel, the following vulnerability has been resolved: xhci: Handle TD clearing for multiple streams case When multiple streams are in use…

PriorityP340high7.8CVSS 3.1
AVLACLPRLUINSUCHIHAH
EPSS
0.29%
21.1th percentile
In the Linux kernel, the following vulnerability has been resolved: xhci: Handle TD clearing for multiple streams case When multiple streams are in use, multiple TDs might be in flight when an endpoint is stopped. We need to issue a Set TR Dequeue Pointer for each, to ensure everything is reset properly and the caches cleared. Change the logic so that any N>1 TDs found active for different streams are deferred until after the first one is processed, calling xhci_invalidate_cancelled_tds() again from xhci_handle_cmd_set_deq() to queue another command until we are done with all of them. Also change the error/"should never happen" paths to ensure we at least clear any affected TDs, even if we can't issue a command to clear the hardware cache, and complain loudly with an xhci_warn() if this ever happens. This problem case dates back to commit e9df17eb1408 ("USB: xhci: Correct assumptions about number of rings per endpoint.") early on in the XHCI driver's life, when stream support was first added. It was then identified but not fixed nor made into a warning in commit 674f8438c121 ("xhci: split handling halted endpoints into two steps"), which added a FIXME comment for the problem case (without materially changing the behavior as far as I can tell, though the new logic made the problem more obvious). Then later, in commit 94f339147fc3 ("xhci: Fix failure to give back some cached cancelled URBs."), it was acknowledged again. [Mathias: commit 94f339147fc3 ("xhci: Fix failure to give back some cached cancelled URBs.") was a targeted regression fix to the previously mentioned patch. Users reported issues with usb stuck after unmounting/disconnecting UAS devices. This rolled back the TD clearing of multiple streams to its original state.] Apparently the commit author was aware of the problem (yet still chose to submit it): It was still mentioned as a FIXME, an xhci_dbg() was added to log the problem condition, and the remaining issue was mentioned in the commit descripti

Affected

18 ranges
VendorProductVersion rangeFixed in
debianlinux< linux 6.1.99-1 (bookworm)linux 6.1.99-1 (bookworm)
debianlinux-6.1< linux 6.1.99-1 (bookworm)linux 6.1.99-1 (bookworm)
linuxlinux
linuxlinux>= e9df17eb1408cfafa3d1844bfc7f22c7237b31b8 < 26460c1afa311524f588e288a4941432f0de622826460c1afa311524f588e288a4941432f0de6228
linuxlinux>= e9df17eb1408cfafa3d1844bfc7f22c7237b31b8 < 633f72cb6124ecda97b641fbc119340bd88d51a9633f72cb6124ecda97b641fbc119340bd88d51a9
linuxlinux>= e9df17eb1408cfafa3d1844bfc7f22c7237b31b8 < 949be4ec5835e0ccb3e2a8ab0e46179cb5512518949be4ec5835e0ccb3e2a8ab0e46179cb5512518
linuxlinux>= e9df17eb1408cfafa3d1844bfc7f22c7237b31b8 < 61593dc413c3655e4328a351555235bc3089486a61593dc413c3655e4328a351555235bc3089486a
linuxlinux>= e9df17eb1408cfafa3d1844bfc7f22c7237b31b8 < 5ceac4402f5d975e5a01c806438eb4e5547715775ceac4402f5d975e5a01c806438eb4e554771577
linuxlinux_kernel
linuxlinux_kernel>= 0 < 6.1.99-16.1.99-1
linuxlinux_kernel>= 0 < 6.9.7-16.9.7-1
linuxlinux_kernel>= 0 < 6.9.7-16.9.7-1
linuxlinux_kernel>= 0 < 5.15.0-121.1315.15.0-121.131
linuxlinux_kernel>= 0 < 6.8.0-44.446.8.0-44.44
linuxlinux_kernel>= 2.6.35 < 5.15.1625.15.162
linuxlinux_kernel>= 5.16 < 6.1.956.1.95
linuxlinux_kernel>= 6.2 < 6.6.356.6.35
linuxlinux_kernel>= 6.7 < 6.9.66.9.6

CVSS provenance

nvdv3.17.8HIGHCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
osv7.8HIGH
vendor_debian7.8HIGH
vendor_redhat7.8HIGH
vendor_ubuntu6.3MEDIUM
Stop checking back — get the weekly exploitation signal.

Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.