cbcvebase.
CVE-2022-48760
published 2024-06-20

CVE-2022-48760: In the Linux kernel, the following vulnerability has been resolved: USB: core: Fix hang in usb_kill_urb by adding memory barriers The syzbot fuzzer has…

PriorityP431high7.1CVSS 3.1
AVLACLPRLUINSUCHINAH
EPSS
0.19%
8.4th percentile
In the Linux kernel, the following vulnerability has been resolved: USB: core: Fix hang in usb_kill_urb by adding memory barriers The syzbot fuzzer has identified a bug in which processes hang waiting for usb_kill_urb() to return. It turns out the issue is not unlinking the URB; that works just fine. Rather, the problem arises when the wakeup notification that the URB has completed is not received. The reason is memory-access ordering on SMP systems. In outline form, usb_kill_urb() and __usb_hcd_giveback_urb() operating concurrently on different CPUs perform the following actions: CPU 0 CPU 1 ---------------------------- --------------------------------- usb_kill_urb(): __usb_hcd_giveback_urb(): ... ... atomic_inc(&urb->reject); atomic_dec(&urb->use_count); ... ... wait_event(usb_kill_urb_queue, atomic_read(&urb->use_count) == 0); if (atomic_read(&urb->reject)) wake_up(&usb_kill_urb_queue); Confining your attention to urb->reject and urb->use_count, you can see that the overall pattern of accesses on CPU 0 is: write urb->reject, then read urb->use_count; whereas the overall pattern of accesses on CPU 1 is: write urb->use_count, then read urb->reject. This pattern is referred to in memory-model circles as SB (for "Store Buffering"), and it is well known that without suitable enforcement of the desired order of accesses -- in the form of memory barriers -- it is entirely possible for one or both CPUs to execute their reads ahead of their writes. The end result will be that sometimes CPU 0 sees the old un-decremented value of urb->use_count while CPU 1 sees the old un-incremented value of urb->reject. Consequently CPU 0 ends up on the wait queue and never gets woken up, leading to the observed hang in usb_kill_urb(). The same pattern of accesses occurs in usb_poison_urb() and the failure pathway of usb_hcd_submit_urb(). The problem is fixed by adding suitable memory barriers. To provide proper memory-access ordering in the SB pattern, a full barrier is requi

Affected

24 ranges
VendorProductVersion rangeFixed in
debianlinux< linux 5.16.7-1 (bookworm)linux 5.16.7-1 (bookworm)
linuxlinux——
linuxlinux>= 49367d8f1d9f26482cf7089489e90f0afd0a942c < 5f138ef224dffd15d5e5c5b095859719e00384275f138ef224dffd15d5e5c5b095859719e0038427
linuxlinux>= 49367d8f1d9f26482cf7089489e90f0afd0a942c < b50f5ca60475710bbc9a3af32fbfc17b1e69c2f0b50f5ca60475710bbc9a3af32fbfc17b1e69c2f0
linuxlinux>= 49367d8f1d9f26482cf7089489e90f0afd0a942c < 546ba238535d925254e0b3f12012a5c55801e2f3546ba238535d925254e0b3f12012a5c55801e2f3
linuxlinux>= 49367d8f1d9f26482cf7089489e90f0afd0a942c < 5904dfd3ddaff3bf4a41c3baf0a8e8f31ed4599b5904dfd3ddaff3bf4a41c3baf0a8e8f31ed4599b
linuxlinux>= 49367d8f1d9f26482cf7089489e90f0afd0a942c < 9c61fce322ac2ef7fecf025285353570d60e41d69c61fce322ac2ef7fecf025285353570d60e41d6
linuxlinux>= 49367d8f1d9f26482cf7089489e90f0afd0a942c < e3b131e30e612ff0e32de6c1cb4f69f89db29193e3b131e30e612ff0e32de6c1cb4f69f89db29193
linuxlinux>= 49367d8f1d9f26482cf7089489e90f0afd0a942c < 9340226388c66a7e090ebb00e91ed64a753b6c269340226388c66a7e090ebb00e91ed64a753b6c26
linuxlinux>= 49367d8f1d9f26482cf7089489e90f0afd0a942c < c9a18f7c5b071dce5e6939568829d40994866ab0c9a18f7c5b071dce5e6939568829d40994866ab0
linuxlinux>= 49367d8f1d9f26482cf7089489e90f0afd0a942c < 26fbe9772b8c459687930511444ce443011f86bf26fbe9772b8c459687930511444ce443011f86bf
linuxlinux_kernel< 4.4.3024.4.302
linuxlinux_kernel——
linuxlinux_kernel>= 0 < 5.10.103-15.10.103-1
linuxlinux_kernel>= 0 < 5.16.7-15.16.7-1
linuxlinux_kernel>= 0 < 5.16.7-15.16.7-1
linuxlinux_kernel>= 0 < 5.16.7-15.16.7-1
linuxlinux_kernel>= 4.10 < 4.14.2654.14.265
linuxlinux_kernel>= 4.15 < 4.19.2284.19.228
linuxlinux_kernel>= 4.20 < 5.4.1765.4.176
linuxlinux_kernel>= 4.5 < 4.9.3004.9.300
linuxlinux_kernel>= 5.11 < 5.15.195.15.19
linuxlinux_kernel>= 5.16 < 5.16.55.16.5
linuxlinux_kernel>= 5.5 < 5.10.965.10.96

CVSS provenance

nvdv3.17.1HIGHCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
osv7.1HIGH
vendor_debian7.1HIGH
vendor_redhat7.1HIGH
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.