{"id":"DEBIAN-CVE-2022-48760","details":"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\t\t\t\t\tCPU 1 ----------------------------\t\t--------------------------------- usb_kill_urb():\t\t\t\t__usb_hcd_giveback_urb():   ...\t\t\t\t\t  ...   atomic_inc(&urb-\u003ereject);\t\t  atomic_dec(&urb-\u003euse_count);   ...\t\t\t\t\t  ...   wait_event(usb_kill_urb_queue, \tatomic_read(&urb-\u003euse_count) == 0); \t\t\t\t\t  if (atomic_read(&urb-\u003ereject)) \t\t\t\t\t\twake_up(&usb_kill_urb_queue);  Confining your attention to urb-\u003ereject and urb-\u003euse_count, you can see that the overall pattern of accesses on CPU 0 is:  \twrite urb-\u003ereject, then read urb-\u003euse_count;  whereas the overall pattern of accesses on CPU 1 is:  \twrite urb-\u003euse_count, then read urb-\u003ereject.  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-\u003euse_count while CPU 1 sees the old un-incremented value of urb-\u003ereject.  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 required on both CPUs.  The atomic_inc() and atomic_dec() accesses themselves don't provide any memory ordering, but since they are present, we can use the optimized smp_mb__after_atomic() memory barrier in the various routines to obtain the desired effect.  This patch adds the necessary memory barriers.","modified":"2026-09-01T16:05:29.120861302Z","published":"2024-06-20T12:15:14.110Z","upstream":["CVE-2022-48760"],"references":[{"type":"ADVISORY","url":"https://security-tracker.debian.org/tracker/CVE-2022-48760"}],"affected":[{"package":{"name":"linux","ecosystem":"Debian:12","purl":"pkg:deb/debian/linux?arch=source&distro=bookworm"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.16.7-1"}]}],"ecosystem_specific":{"urgency":"not yet assigned"},"database_specific":{"source":"https://storage.googleapis.com/osv-test-debian-osv/debian-cve-osv/DEBIAN-CVE-2022-48760.json"}},{"package":{"name":"linux","ecosystem":"Debian:13","purl":"pkg:deb/debian/linux?arch=source&distro=trixie"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.16.7-1"}]}],"ecosystem_specific":{"urgency":"not yet assigned"},"database_specific":{"source":"https://storage.googleapis.com/osv-test-debian-osv/debian-cve-osv/DEBIAN-CVE-2022-48760.json"}},{"package":{"name":"linux","ecosystem":"Debian:14","purl":"pkg:deb/debian/linux?arch=source&distro=forky"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.16.7-1"}]}],"ecosystem_specific":{"urgency":"not yet assigned"},"database_specific":{"source":"https://storage.googleapis.com/osv-test-debian-osv/debian-cve-osv/DEBIAN-CVE-2022-48760.json"}}],"schema_version":"1.9.0","severity":[{"type":"CVSS_V3","score":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H"}]}