USB: core: Fix hang in usb_kill_urb by adding memory barriers
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 some
- Products
- Kernel
- Affected versions
- Not specified
- Fixed versions
- 4.14.265, 4.19.228, 4.4.302, 4.9.300, 5.10.96, 5.15.19, 5.16.5, 5.4.176
- CVEs
- CVE-2022-48760
- Confirmed fixed CVEs
- Not specified
- Updated in this feed
- 3 Nov 2026, 17:45 UTC · Revision 1
Source evidence
USB: core: Fix hang in usb_kill_urb by adding memory barriers
core-osv · Original sourcePublished 20 Jun 2024, 11:13 UTC
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 some
osv:CVE-2022-48760
Kernel
Fixed versions: 4.4.302, 4.9.300, 4.14.265, 4.19.228, 5.4.176, 5.10.96, 5.15.19, 5.16.5
Complete source record
{
"id": "264a2a69b7183d489967609eda7b0baecb400e3271dceb2bbf42c941b876b052",
"url": "https://osv.dev/vulnerability/CVE-2022-48760",
"method": "structured",
"payload": {
"kind": "advisory",
"title": "USB: core: Fix hang in usb_kill_urb by adding memory barriers",
"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 some",
"evidence": "osv:CVE-2022-48760",
"products": [
{
"name": {
"value": "Kernel",
"evidence": "/affected/1/package/name"
},
"prerequisites": [],
"fixed_versions": [
{
"value": "4.4.302",
"evidence": "/affected/1/ranges"
},
{
"value": "4.9.300",
"evidence": "/affected/1/ranges"
},
{
"value": "4.14.265",
"evidence": "/affected/1/ranges"
},
{
"value": "4.19.228",
"evidence": "/affected/1/ranges"
},
{
"value": "5.4.176",
"evidence": "/affected/1/ranges"
},
{
"value": "5.10.96",
"evidence": "/affected/1/ranges"
},
{
"value": "5.15.19",
"evidence": "/affected/1/ranges"
},
{
"value": "5.16.5",
"evidence": "/affected/1/ranges"
}
],
"affected_versions": []
}
],
"severity": "unknown",
"structured": {
"id": "CVE-2022-48760",
"aliases": [
"CVE-2022-48760"
],
"affected": [
{
"ranges": [
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "49367d8f1d9f26482cf7089489e90f0afd0a942c"
},
{
"fixed": "5f138ef224dffd15d5e5c5b095859719e0038427"
},
{
"fixed": "b50f5ca60475710bbc9a3af32fbfc17b1e69c2f0"
},
{
"fixed": "546ba238535d925254e0b3f12012a5c55801e2f3"
},
{
"fixed": "5904dfd3ddaff3bf4a41c3baf0a8e8f31ed4599b"
},
{
"fixed": "9c61fce322ac2ef7fecf025285353570d60e41d6"
},
{
"fixed": "e3b131e30e612ff0e32de6c1cb4f69f89db29193"
},
{
"fixed": "9340226388c66a7e090ebb00e91ed64a753b6c26"
},
{
"fixed": "c9a18f7c5b071dce5e6939568829d40994866ab0"
},
{
"fixed": "26fbe9772b8c459687930511444ce443011f86bf"
}
]
}
],
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2022-48760.json"
}
},
{
"ranges": [
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "2.6.29"
},
{
"fixed": "4.4.302"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "4.5.0"
},
{
"fixed": "4.9.300"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "4.10.0"
},
{
"fixed": "4.14.265"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "4.15.0"
},
{
"fixed": "4.19.228"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "4.20.0"
},
{
"fixed": "5.4.176"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "5.5.0"
},
{
"fixed": "5.10.96"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "5.11.0"
},
{
"fixed": "5.15.19"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "5.16.0"
},
{
"fixed": "5.16.5"
}
]
}
],
"package": {
"name": "Kernel",
"ecosystem": "Linux"
},
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2022-48760.json"
}
}
],
"modified": "2026-10-28T02:30:31.312715532Z",
"provider": "osv",
"references": [
"https://git.kernel.org/stable/c/26fbe9772b8c459687930511444ce443011f86bf",
"https://git.kernel.org/stable/c/546ba238535d925254e0b3f12012a5c55801e2f3",
"https://git.kernel.org/stable/c/5904dfd3ddaff3bf4a41c3baf0a8e8f31ed4599b",
"https://git.kernel.org/stable/c/5f138ef224dffd15d5e5c5b095859719e0038427",
"https://git.kernel.org/stable/c/9340226388c66a7e090ebb00e91ed64a753b6c26",
"https://git.kernel.org/stable/c/9c61fce322ac2ef7fecf025285353570d60e41d6",
"https://git.kernel.org/stable/c/b50f5ca60475710bbc9a3af32fbfc17b1e69c2f0",
"https://git.kernel.org/stable/c/c9a18f7c5b071dce5e6939568829d40994866ab0",
"https://git.kernel.org/stable/c/e3b131e30e612ff0e32de6c1cb4f69f89db29193",
"https://github.com/CVEProject/cvelistV5/tree/main/cves/2022/48xxx/CVE-2022-48760.json",
"https://nvd.nist.gov/vuln/detail/CVE-2022-48760",
"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git"
],
"provider_metadata": {
"cna_assigner": "Linux",
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2022/48xxx/CVE-2022-48760.json"
}
},
"related_cves": [
{
"value": "CVE-2022-48760",
"evidence": "/id"
}
],
"security_relevant": true,
"severity_evidence": null
},
"source_id": "core-osv",
"document_id": 497924,
"published_at": "2024-06-20T11:13:38.532+00:00"
}