Skip to content
Fencer Vulns
high 7.1

CVE-2022-48760 json

USB: core: Fix hang in usb_kill_urb by adding memory barriers

published 2024-06-20 2 y ago modified 2026-06-17 4 mo ago also EUVD-2022-53639

cvss
7.1
version 3.1, NVD
cisa kev
Not listed
not in CISA's catalog
epss
0.2%
EPSS 0.2% chance of exploitation in 30 days, percentile 8%
public exploits
0
none known

Summary

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.

Patch / fix

  • Linux Linux 4.4.302, 4.9.300, 4.14.265, 4.19.228, 5.4.176, 5.10.96, 5.15.19, 5.16.5, 5.17
  • linux Debian 14, Debian 13, Debian 12 5.16.7-1

debian advisories DEBIAN-CVE-2022-48760

  • linux Ubuntu 18.04 LTS 4.15.0-176.185
  • linux Ubuntu 20.04 LTS 5.4.0-109.123
  • linux-aws Ubuntu 18.04 LTS 4.15.0-1127.136
  • linux-aws Ubuntu 20.04 LTS 5.4.0-1072.77
  • linux-gcp Ubuntu 20.04 LTS 5.4.0-1072.77
  • linux-ibm Ubuntu 20.04 LTS 5.4.0-1020.22
  • linux-iot Ubuntu 20.04 LTS 5.4.0-1004.6
  • linux-kvm Ubuntu 18.04 LTS 4.15.0-1113.116

ubuntu advisories UBUNTU-CVE-2022-48760

Ubuntu security data © Canonical Ltd., from https://github.com/canonical/ubuntu-security-notices via OSV; changed: normalised to fixed package versions per release. CC BY-SA 4.0

  • kernel RHEL 8 4.18.0-553.22.1.el8_10
  • perf RHEL 8 4.18.0-553.22.1.el8_10
  • bpftool RHEL 8 4.18.0-553.22.1.el8_10
  • kernel-core RHEL 8 4.18.0-553.22.1.el8_10
  • kernel-tools RHEL 8 4.18.0-553.22.1.el8_10
  • python3-perf RHEL 8 4.18.0-553.22.1.el8_10
  • kernel-modules RHEL 8 4.18.0-553.22.1.el8_10
  • kernel-zfcpdump RHEL 8 4.18.0-553.22.1.el8_10

red hat advisories RHSA-2024:7000RHSA-2024:7001

  • dtb-aarch64 openSUSE Leap 15.5 5.14.21-150500.55.73.1
  • kernel-64kb SLE Module for Basesystem 15 SP5, openSUSE Leap 15.5 5.14.21-150500.55.73.1
  • kernel-syms SLE Module for Development Tools 15 SP5, openSUSE Leap 15.5 5.14.21-150500.55.73.1
  • kernel-obs-qa openSUSE Leap 15.5 5.14.21-150500.55.73.1
  • kernel-source SLE Module for Development Tools 15 SP5, SLE Module for Basesystem 15 SP5, openSUSE Leap 15.5 5.14.21-150500.55.73.1
  • kernel-default SLE Workstation Extension 15 SP5, SLE Module for Legacy 15 SP5, SLE Module for Basesystem 15 SP5 +5 more 5.14.21-150500.55.73.1
  • kernel-kvmsmall openSUSE Leap 15.5 5.14.21-150500.55.73.1
  • kernel-zfcpdump SLE Module for Basesystem 15 SP5, openSUSE Leap 15.5 5.14.21-150500.55.73.1

suse advisories SUSE-SU-2024:2939-1SUSE-SU-2024:2929-1SUSE-SU-2024:2902-1SUSE-SU-2024:2561-1SUSE-SU-2024:2394-1SUSE-SU-2024:2384-1

  • kernel AlmaLinux 8 4.18.0-553.22.1.el8_10
  • perf AlmaLinux 8 4.18.0-553.22.1.el8_10
  • bpftool AlmaLinux 8 4.18.0-553.22.1.el8_10
  • kernel-core AlmaLinux 8 4.18.0-553.22.1.el8_10
  • kernel-tools AlmaLinux 8 4.18.0-553.22.1.el8_10
  • python3-perf AlmaLinux 8 4.18.0-553.22.1.el8_10
  • kernel-modules AlmaLinux 8 4.18.0-553.22.1.el8_10
  • kernel-zfcpdump AlmaLinux 8 4.18.0-553.22.1.el8_10

almalinux advisories ALSA-2024:7000ALSA-2024:7001

  • kernel Rocky Linux 8 4.18.0-553.22.1.el8_10
  • kernel-rt Rocky Linux 8 4.18.0-553.22.1.rt7.363.el8_10

rocky linux advisories RLSA-2024:7000RLSA-2024:7001

Vendor advisories

What the vendors themselves say about their products: affected, fixed or not affected, and what to do.

red hat product security vex CVE-2022-48760 updated cvss 4.1

kernel: USB: core: Fix hang in usb_kill_urb by adding memory barriers

  • Red Hat Enterprise Linux 6 perf, kernel, python-perf, kernel-kdump, kernel-firmware, kernel-bootwrapper, +1 more Red Hat Enterprise Linux 7 perf, kernel, bpftool, kernel-rt, python-perf, kernel-kdump, +8 more
    affected: no fix planned “Out of support scope”
  • Red Hat Enterprise Linux 9 rv, perf, rtla, kernel, bpftool, libperf, +82 more
    affected: no fix available “Fix deferred”
  • Red Hat Enterprise Linux BaseOS (v. 8) perf 4.18.0-553.22.1.el8_10, kernel 4.18.0-553.22.1.el8_10, bpftool 4.18.0-553.22.1.el8_10, kernel-core 4.18.0-553.22.1.el8_10, kernel-tools 4.18.0-553.22.1.el8_10, python3-perf 4.18.0-553.22.1.el8_10, +15 more Red Hat Enterprise Linux CRB (v. 8) kernel-debuginfo-common-x86_64 4.18.0-553.22.1.el8_10, kernel-debuginfo-common-aarch64 4.18.0-553.22.1.el8_10, kernel-debuginfo-common-ppc64le 4.18.0-553.22.1.el8_10
    fixed: vendor fix RHSA-2024:7000
  • Red Hat Enterprise Linux NFV (v. 8) kernel-rt 4.18.0-553.22.1.rt7.363.el8_10, kernel-rt-kvm 4.18.0-553.22.1.rt7.363.el8_10, kernel-rt-core 4.18.0-553.22.1.rt7.363.el8_10, kernel-rt-modules 4.18.0-553.22.1.rt7.363.el8_10, kernel-rt-debug-kvm 4.18.0-553.22.1.rt7.363.el8_10, kernel-rt-debug-core 4.18.0-553.22.1.rt7.363.el8_10, +4 more Red Hat Enterprise Linux RT (v. 8) kernel-rt 4.18.0-553.22.1.rt7.363.el8_10, kernel-rt-core 4.18.0-553.22.1.rt7.363.el8_10, kernel-rt-modules 4.18.0-553.22.1.rt7.363.el8_10, kernel-rt-debug-core 4.18.0-553.22.1.rt7.363.el8_10, kernel-rt-debug-modules 4.18.0-553.22.1.rt7.363.el8_10, kernel-rt-modules-extra 4.18.0-553.22.1.rt7.363.el8_10, +2 more
    fixed: vendor fix RHSA-2024:7001
  • Red Hat OpenShift AI 8 rhoai/odh-rhel8-operator v2.13.1-2, rhoai/odh-dashboard-rhel8 v2.13.1-1, rhoai/odh-modelmesh-rhel8 v2.13.1-1, rhoai/odh-operator-bundle v2.13.1-2, rhoai/odh-rhel8-operator v2.14.0-24, rhoai/odh-dashboard-rhel8 v2.14.0-11, +56 more
    fixed: vendor fix RHBA-2024:8413

Red Hat CSAF VEX © Red Hat, Inc., from https://security.access.redhat.com/data/csaf/v2/vex/; changed: reduced to product statuses and remediations. CC BY 4.0 · csaf

CISA SSVC

Exploitation
none
Automatable
no
Technical impact
partial
Assessed
2 y ago

Exploit prediction

0.19% chance of exploitation in the next 30 days, higher than 8% of all scored CVEs (FIRST EPSS, 2026-11-08).

CVSS scores

assigned by version score vector
NVD 3.1 7.1 CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H

Affected products

  • Linux Linux

Classification

Weakness
Technology feeds

References

Sources

Fencer Vulns keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.