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.
Published: 2024-06-20
Score: 7.1 High
EPSS: < 1% Very Low
KEV: No
Impact: n/a
Action: n/a
AI Analysis

No analysis available yet.

Remediation

No remediation available yet.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Wed, 17 Sep 2025 17:00:00 +0000

Type Values Removed Values Added
First Time appeared Linux
Linux linux Kernel
Weaknesses CWE-667
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:5.17:rc1:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
Metrics cvssV3_1

{'score': 4.1, 'vector': 'CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:H'}

cvssV3_1

{'score': 7.1, 'vector': 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H'}


Thu, 19 Dec 2024 09:15:00 +0000

Type Values Removed Values Added
Metrics ssvc

{'options': {'Automatable': 'no', 'Exploitation': 'none', 'Technical Impact': 'partial'}, 'version': '2.0.3'}


Tue, 24 Sep 2024 11:00:00 +0000

Type Values Removed Values Added
CPEs cpe:/o:redhat:enterprise_linux:8

Tue, 24 Sep 2024 06:30:00 +0000

Type Values Removed Values Added
First Time appeared Redhat
Redhat enterprise Linux
CPEs cpe:/a:redhat:enterprise_linux:8::nfv
Vendors & Products Redhat
Redhat enterprise Linux

Subscriptions

Linux Linux Kernel
Redhat Enterprise Linux
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2025-12-23T13:20:18.737Z

Reserved: 2024-06-20T11:09:39.059Z

Link: CVE-2022-48760

cve-icon Vulnrichment

Updated: 2024-08-03T15:25:01.565Z

cve-icon NVD

Status : Analyzed

Published: 2024-06-20T12:15:14.110

Modified: 2025-09-17T16:49:52.623

Link: CVE-2022-48760

cve-icon Redhat

Severity : Low

Publid Date: 2024-06-20T00:00:00Z

Links: CVE-2022-48760 - Bugzilla

cve-icon OpenCVE Enrichment

No data.

Weaknesses