CVE-2022-48760 (GCVE-0-2022-48760)
Vulnerability from cvelistv5 – Published: 2024-06-20 11:13 – Updated: 2026-05-11 18:46
VLAI
EPSS
VEX
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 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.
Severity
No CVSS data available.
SSVC
Exploitation: none
Automatable: no
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2024-06-20 14:49 UTC
Assigner
References
9 references
Impacted products
2 products
| Vendor | Product | Version | CPE status | |
|---|---|---|---|---|
| Linux | Linux |
Affected:
49367d8f1d9f26482cf7089489e90f0afd0a942c , < 5f138ef224dffd15d5e5c5b095859719e0038427
(git)
Affected: 49367d8f1d9f26482cf7089489e90f0afd0a942c , < b50f5ca60475710bbc9a3af32fbfc17b1e69c2f0 (git) Affected: 49367d8f1d9f26482cf7089489e90f0afd0a942c , < 546ba238535d925254e0b3f12012a5c55801e2f3 (git) Affected: 49367d8f1d9f26482cf7089489e90f0afd0a942c , < 5904dfd3ddaff3bf4a41c3baf0a8e8f31ed4599b (git) Affected: 49367d8f1d9f26482cf7089489e90f0afd0a942c , < 9c61fce322ac2ef7fecf025285353570d60e41d6 (git) Affected: 49367d8f1d9f26482cf7089489e90f0afd0a942c , < e3b131e30e612ff0e32de6c1cb4f69f89db29193 (git) Affected: 49367d8f1d9f26482cf7089489e90f0afd0a942c , < 9340226388c66a7e090ebb00e91ed64a753b6c26 (git) Affected: 49367d8f1d9f26482cf7089489e90f0afd0a942c , < c9a18f7c5b071dce5e6939568829d40994866ab0 (git) Affected: 49367d8f1d9f26482cf7089489e90f0afd0a942c , < 26fbe9772b8c459687930511444ce443011f86bf (git) |
guessed | |
| Linux | Linux |
Affected:
2.6.29
Unaffected: 0 , < 2.6.29 (semver) Unaffected: 4.4.302 , ≤ 4.4.* (semver) Unaffected: 4.9.300 , ≤ 4.9.* (semver) Unaffected: 4.14.265 , ≤ 4.14.* (semver) Unaffected: 4.19.228 , ≤ 4.19.* (semver) Unaffected: 5.4.176 , ≤ 5.4.* (semver) Unaffected: 5.10.96 , ≤ 5.10.* (semver) Unaffected: 5.15.19 , ≤ 5.15.* (semver) Unaffected: 5.16.5 , ≤ 5.16.* (semver) Unaffected: 5.17 , ≤ * (original_commit_for_fix) |
guessed |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2022-48760",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2024-06-20T14:49:44.326446Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2024-06-20T14:50:00.838Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
},
{
"providerMetadata": {
"dateUpdated": "2024-08-03T15:25:01.565Z",
"orgId": "af854a3a-2127-422b-91ae-364da2661108",
"shortName": "CVE"
},
"references": [
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/5f138ef224dffd15d5e5c5b095859719e0038427"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/b50f5ca60475710bbc9a3af32fbfc17b1e69c2f0"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/546ba238535d925254e0b3f12012a5c55801e2f3"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/5904dfd3ddaff3bf4a41c3baf0a8e8f31ed4599b"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/9c61fce322ac2ef7fecf025285353570d60e41d6"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/e3b131e30e612ff0e32de6c1cb4f69f89db29193"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/9340226388c66a7e090ebb00e91ed64a753b6c26"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/c9a18f7c5b071dce5e6939568829d40994866ab0"
},
{
"tags": [
"x_transferred"
],
"url": "https://git.kernel.org/stable/c/26fbe9772b8c459687930511444ce443011f86bf"
}
],
"title": "CVE Program Container"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"drivers/usb/core/hcd.c",
"drivers/usb/core/urb.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "5f138ef224dffd15d5e5c5b095859719e0038427",
"status": "affected",
"version": "49367d8f1d9f26482cf7089489e90f0afd0a942c",
"versionType": "git"
},
{
"lessThan": "b50f5ca60475710bbc9a3af32fbfc17b1e69c2f0",
"status": "affected",
"version": "49367d8f1d9f26482cf7089489e90f0afd0a942c",
"versionType": "git"
},
{
"lessThan": "546ba238535d925254e0b3f12012a5c55801e2f3",
"status": "affected",
"version": "49367d8f1d9f26482cf7089489e90f0afd0a942c",
"versionType": "git"
},
{
"lessThan": "5904dfd3ddaff3bf4a41c3baf0a8e8f31ed4599b",
"status": "affected",
"version": "49367d8f1d9f26482cf7089489e90f0afd0a942c",
"versionType": "git"
},
{
"lessThan": "9c61fce322ac2ef7fecf025285353570d60e41d6",
"status": "affected",
"version": "49367d8f1d9f26482cf7089489e90f0afd0a942c",
"versionType": "git"
},
{
"lessThan": "e3b131e30e612ff0e32de6c1cb4f69f89db29193",
"status": "affected",
"version": "49367d8f1d9f26482cf7089489e90f0afd0a942c",
"versionType": "git"
},
{
"lessThan": "9340226388c66a7e090ebb00e91ed64a753b6c26",
"status": "affected",
"version": "49367d8f1d9f26482cf7089489e90f0afd0a942c",
"versionType": "git"
},
{
"lessThan": "c9a18f7c5b071dce5e6939568829d40994866ab0",
"status": "affected",
"version": "49367d8f1d9f26482cf7089489e90f0afd0a942c",
"versionType": "git"
},
{
"lessThan": "26fbe9772b8c459687930511444ce443011f86bf",
"status": "affected",
"version": "49367d8f1d9f26482cf7089489e90f0afd0a942c",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"drivers/usb/core/hcd.c",
"drivers/usb/core/urb.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "2.6.29"
},
{
"lessThan": "2.6.29",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "4.4.*",
"status": "unaffected",
"version": "4.4.302",
"versionType": "semver"
},
{
"lessThanOrEqual": "4.9.*",
"status": "unaffected",
"version": "4.9.300",
"versionType": "semver"
},
{
"lessThanOrEqual": "4.14.*",
"status": "unaffected",
"version": "4.14.265",
"versionType": "semver"
},
{
"lessThanOrEqual": "4.19.*",
"status": "unaffected",
"version": "4.19.228",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.176",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.96",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.19",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.16.*",
"status": "unaffected",
"version": "5.16.5",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "5.17",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "4.4.302",
"versionStartIncluding": "2.6.29",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "4.9.300",
"versionStartIncluding": "2.6.29",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "4.14.265",
"versionStartIncluding": "2.6.29",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "4.19.228",
"versionStartIncluding": "2.6.29",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.4.176",
"versionStartIncluding": "2.6.29",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.10.96",
"versionStartIncluding": "2.6.29",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.15.19",
"versionStartIncluding": "2.6.29",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.16.5",
"versionStartIncluding": "2.6.29",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.17",
"versionStartIncluding": "2.6.29",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nUSB: core: Fix hang in usb_kill_urb by adding memory barriers\n\nThe syzbot fuzzer has identified a bug in which processes hang waiting\nfor usb_kill_urb() to return. It turns out the issue is not unlinking\nthe URB; that works just fine. Rather, the problem arises when the\nwakeup notification that the URB has completed is not received.\n\nThe reason is memory-access ordering on SMP systems. In outline form,\nusb_kill_urb() and __usb_hcd_giveback_urb() operating concurrently on\ndifferent CPUs perform the following actions:\n\nCPU 0\t\t\t\t\tCPU 1\n----------------------------\t\t---------------------------------\nusb_kill_urb():\t\t\t\t__usb_hcd_giveback_urb():\n ...\t\t\t\t\t ...\n atomic_inc(\u0026urb-\u003ereject);\t\t atomic_dec(\u0026urb-\u003euse_count);\n ...\t\t\t\t\t ...\n wait_event(usb_kill_urb_queue,\n\tatomic_read(\u0026urb-\u003euse_count) == 0);\n\t\t\t\t\t if (atomic_read(\u0026urb-\u003ereject))\n\t\t\t\t\t\twake_up(\u0026usb_kill_urb_queue);\n\nConfining your attention to urb-\u003ereject and urb-\u003euse_count, you can\nsee that the overall pattern of accesses on CPU 0 is:\n\n\twrite urb-\u003ereject, then read urb-\u003euse_count;\n\nwhereas the overall pattern of accesses on CPU 1 is:\n\n\twrite urb-\u003euse_count, then read urb-\u003ereject.\n\nThis pattern is referred to in memory-model circles as SB (for \"Store\nBuffering\"), and it is well known that without suitable enforcement of\nthe desired order of accesses -- in the form of memory barriers -- it\nis entirely possible for one or both CPUs to execute their reads ahead\nof their writes. The end result will be that sometimes CPU 0 sees the\nold un-decremented value of urb-\u003euse_count while CPU 1 sees the old\nun-incremented value of urb-\u003ereject. Consequently CPU 0 ends up on\nthe wait queue and never gets woken up, leading to the observed hang\nin usb_kill_urb().\n\nThe same pattern of accesses occurs in usb_poison_urb() and the\nfailure pathway of usb_hcd_submit_urb().\n\nThe problem is fixed by adding suitable memory barriers. To provide\nproper memory-access ordering in the SB pattern, a full barrier is\nrequired on both CPUs. The atomic_inc() and atomic_dec() accesses\nthemselves don\u0027t provide any memory ordering, but since they are\npresent, we can use the optimized smp_mb__after_atomic() memory\nbarrier in the various routines to obtain the desired effect.\n\nThis patch adds the necessary memory barriers."
}
],
"providerMetadata": {
"dateUpdated": "2026-05-11T18:46:24.191Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/5f138ef224dffd15d5e5c5b095859719e0038427"
},
{
"url": "https://git.kernel.org/stable/c/b50f5ca60475710bbc9a3af32fbfc17b1e69c2f0"
},
{
"url": "https://git.kernel.org/stable/c/546ba238535d925254e0b3f12012a5c55801e2f3"
},
{
"url": "https://git.kernel.org/stable/c/5904dfd3ddaff3bf4a41c3baf0a8e8f31ed4599b"
},
{
"url": "https://git.kernel.org/stable/c/9c61fce322ac2ef7fecf025285353570d60e41d6"
},
{
"url": "https://git.kernel.org/stable/c/e3b131e30e612ff0e32de6c1cb4f69f89db29193"
},
{
"url": "https://git.kernel.org/stable/c/9340226388c66a7e090ebb00e91ed64a753b6c26"
},
{
"url": "https://git.kernel.org/stable/c/c9a18f7c5b071dce5e6939568829d40994866ab0"
},
{
"url": "https://git.kernel.org/stable/c/26fbe9772b8c459687930511444ce443011f86bf"
}
],
"title": "USB: core: Fix hang in usb_kill_urb by adding memory barriers",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2022-48760",
"datePublished": "2024-06-20T11:13:38.532Z",
"dateReserved": "2024-06-20T11:09:39.059Z",
"dateUpdated": "2026-05-11T18:46:24.191Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2",
"vulnerability-lookup:meta": {
"epss": {
"cve": "CVE-2022-48760",
"date": "2026-09-16",
"epss": "0.00186",
"percentile": "0.08391"
},
"fkie_nvd": {
"descriptions": "[{\"lang\": \"en\", \"value\": \"In the Linux kernel, the following vulnerability has been resolved:\\n\\nUSB: core: Fix hang in usb_kill_urb by adding memory barriers\\n\\nThe syzbot fuzzer has identified a bug in which processes hang waiting\\nfor usb_kill_urb() to return. It turns out the issue is not unlinking\\nthe URB; that works just fine. Rather, the problem arises when the\\nwakeup notification that the URB has completed is not received.\\n\\nThe reason is memory-access ordering on SMP systems. In outline form,\\nusb_kill_urb() and __usb_hcd_giveback_urb() operating concurrently on\\ndifferent CPUs perform the following actions:\\n\\nCPU 0\\t\\t\\t\\t\\tCPU 1\\n----------------------------\\t\\t---------------------------------\\nusb_kill_urb():\\t\\t\\t\\t__usb_hcd_giveback_urb():\\n ...\\t\\t\\t\\t\\t ...\\n atomic_inc(\u0026urb-\u003ereject);\\t\\t atomic_dec(\u0026urb-\u003euse_count);\\n ...\\t\\t\\t\\t\\t ...\\n wait_event(usb_kill_urb_queue,\\n\\tatomic_read(\u0026urb-\u003euse_count) == 0);\\n\\t\\t\\t\\t\\t if (atomic_read(\u0026urb-\u003ereject))\\n\\t\\t\\t\\t\\t\\twake_up(\u0026usb_kill_urb_queue);\\n\\nConfining your attention to urb-\u003ereject and urb-\u003euse_count, you can\\nsee that the overall pattern of accesses on CPU 0 is:\\n\\n\\twrite urb-\u003ereject, then read urb-\u003euse_count;\\n\\nwhereas the overall pattern of accesses on CPU 1 is:\\n\\n\\twrite urb-\u003euse_count, then read urb-\u003ereject.\\n\\nThis pattern is referred to in memory-model circles as SB (for \\\"Store\\nBuffering\\\"), and it is well known that without suitable enforcement of\\nthe desired order of accesses -- in the form of memory barriers -- it\\nis entirely possible for one or both CPUs to execute their reads ahead\\nof their writes. The end result will be that sometimes CPU 0 sees the\\nold un-decremented value of urb-\u003euse_count while CPU 1 sees the old\\nun-incremented value of urb-\u003ereject. Consequently CPU 0 ends up on\\nthe wait queue and never gets woken up, leading to the observed hang\\nin usb_kill_urb().\\n\\nThe same pattern of accesses occurs in usb_poison_urb() and the\\nfailure pathway of usb_hcd_submit_urb().\\n\\nThe problem is fixed by adding suitable memory barriers. To provide\\nproper memory-access ordering in the SB pattern, a full barrier is\\nrequired on both CPUs. The atomic_inc() and atomic_dec() accesses\\nthemselves don\u0027t provide any memory ordering, but since they are\\npresent, we can use the optimized smp_mb__after_atomic() memory\\nbarrier in the various routines to obtain the desired effect.\\n\\nThis patch adds the necessary memory barriers.\"}, {\"lang\": \"es\", \"value\": \"En el kernel de Linux, se resolvi\\u00f3 la siguiente vulnerabilidad: USB: core: corrige el bloqueo en usb_kill_urb agregando barreras de memoria el syzbot fuzzer ha identificado un error en el que los procesos se bloquean esperando que regrese usb_kill_urb(). Resulta que el problema no es desvincular la URB; eso funciona bien. M\\u00e1s bien, el problema surge cuando no se recibe la notificaci\\u00f3n de activaci\\u00f3n de que la URB ha completado. El motivo son los pedidos de acceso a la memoria en los sistemas SMP. En forma resumida, usb_kill_urb() y __usb_hcd_giveback_urb() operando simult\\u00e1neamente en diferentes CPU realizan las siguientes acciones: CPU 0 CPU 1 ------------------------- --- --------------------------------- usb_kill_urb(): __usb_hcd_giveback_urb(): ... ... atomic_inc(\u0026amp;urb-\u0026gt;rechazar); atomic_dec(\u0026amp;urb-\u0026gt;use_count); ... ... wait_event(usb_kill_urb_queue, atomic_read(\u0026amp;urb-\u0026gt;use_count) == 0); if (atomic_read(\u0026amp;urb-\u0026gt;reject)) wake_up(\u0026amp;usb_kill_urb_queue); Limitando su atenci\\u00f3n a urb-\u0026gt;reject y urb-\u0026gt;use_count, puede ver que el patr\\u00f3n general de accesos en la CPU 0 es: escribir urb-\u0026gt;reject, luego leer urb-\u0026gt;use_count; mientras que el patr\\u00f3n general de accesos en la CPU 1 es: escribir urb-\u0026gt;use_count, luego leer urb-\u0026gt;reject. En los c\\u00edrculos de modelos de memoria se hace referencia a este patr\\u00f3n como SB (por \\\"Store Buffering\\\"), y es bien sabido que sin una aplicaci\\u00f3n adecuada del orden deseado de accesos (en forma de barreras de memoria) es completamente posible que una o ambas CPU para ejecutar sus lecturas antes de sus escrituras. El resultado final ser\\u00e1 que a veces la CPU 0 ve el antiguo valor no incrementado de urb-\u0026gt;use_count mientras que la CPU 1 ve el antiguo valor no incrementado de urb-\u0026gt;reject. En consecuencia, la CPU 0 termina en la cola de espera y nunca se activa, lo que provoca el bloqueo observado en usb_kill_urb(). El mismo patr\\u00f3n de accesos ocurre en usb_poison_urb() y la ruta de falla de usb_hcd_submit_urb(). El problema se soluciona agregando barreras de memoria adecuadas. Para proporcionar un orden adecuado de acceso a la memoria en el patr\\u00f3n SB, se requiere una barrera completa en ambas CPU. Los accesos atomic_inc() y atomic_dec() en s\\u00ed no proporcionan ning\\u00fan orden de memoria, pero como est\\u00e1n presentes, podemos usar la barrera de memoria optimizada smp_mb__after_atomic() en las distintas rutinas para obtener el efecto deseado. Este parche agrega las barreras de memoria necesarias.\"}]",
"id": "CVE-2022-48760",
"lastModified": "2024-11-21T07:33:57.913",
"published": "2024-06-20T12:15:14.110",
"references": "[{\"url\": \"https://git.kernel.org/stable/c/26fbe9772b8c459687930511444ce443011f86bf\", \"source\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"}, {\"url\": \"https://git.kernel.org/stable/c/546ba238535d925254e0b3f12012a5c55801e2f3\", \"source\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"}, {\"url\": \"https://git.kernel.org/stable/c/5904dfd3ddaff3bf4a41c3baf0a8e8f31ed4599b\", \"source\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"}, {\"url\": \"https://git.kernel.org/stable/c/5f138ef224dffd15d5e5c5b095859719e0038427\", \"source\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"}, {\"url\": \"https://git.kernel.org/stable/c/9340226388c66a7e090ebb00e91ed64a753b6c26\", \"source\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"}, {\"url\": \"https://git.kernel.org/stable/c/9c61fce322ac2ef7fecf025285353570d60e41d6\", \"source\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"}, {\"url\": \"https://git.kernel.org/stable/c/b50f5ca60475710bbc9a3af32fbfc17b1e69c2f0\", \"source\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"}, {\"url\": \"https://git.kernel.org/stable/c/c9a18f7c5b071dce5e6939568829d40994866ab0\", \"source\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"}, {\"url\": \"https://git.kernel.org/stable/c/e3b131e30e612ff0e32de6c1cb4f69f89db29193\", \"source\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"}, {\"url\": \"https://git.kernel.org/stable/c/26fbe9772b8c459687930511444ce443011f86bf\", \"source\": \"af854a3a-2127-422b-91ae-364da2661108\"}, {\"url\": \"https://git.kernel.org/stable/c/546ba238535d925254e0b3f12012a5c55801e2f3\", \"source\": \"af854a3a-2127-422b-91ae-364da2661108\"}, {\"url\": \"https://git.kernel.org/stable/c/5904dfd3ddaff3bf4a41c3baf0a8e8f31ed4599b\", \"source\": \"af854a3a-2127-422b-91ae-364da2661108\"}, {\"url\": \"https://git.kernel.org/stable/c/5f138ef224dffd15d5e5c5b095859719e0038427\", \"source\": \"af854a3a-2127-422b-91ae-364da2661108\"}, {\"url\": \"https://git.kernel.org/stable/c/9340226388c66a7e090ebb00e91ed64a753b6c26\", \"source\": \"af854a3a-2127-422b-91ae-364da2661108\"}, {\"url\": \"https://git.kernel.org/stable/c/9c61fce322ac2ef7fecf025285353570d60e41d6\", \"source\": \"af854a3a-2127-422b-91ae-364da2661108\"}, {\"url\": \"https://git.kernel.org/stable/c/b50f5ca60475710bbc9a3af32fbfc17b1e69c2f0\", \"source\": \"af854a3a-2127-422b-91ae-364da2661108\"}, {\"url\": \"https://git.kernel.org/stable/c/c9a18f7c5b071dce5e6939568829d40994866ab0\", \"source\": \"af854a3a-2127-422b-91ae-364da2661108\"}, {\"url\": \"https://git.kernel.org/stable/c/e3b131e30e612ff0e32de6c1cb4f69f89db29193\", \"source\": \"af854a3a-2127-422b-91ae-364da2661108\"}]",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Awaiting Analysis"
},
"nvd": "{\"cve\":{\"id\":\"CVE-2022-48760\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2024-06-20T12:15:14.110\",\"lastModified\":\"2026-06-17T05:16:07.523\",\"vulnStatus\":\"Analyzed\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"In the Linux kernel, the following vulnerability has been resolved:\\n\\nUSB: core: Fix hang in usb_kill_urb by adding memory barriers\\n\\nThe syzbot fuzzer has identified a bug in which processes hang waiting\\nfor usb_kill_urb() to return. It turns out the issue is not unlinking\\nthe URB; that works just fine. Rather, the problem arises when the\\nwakeup notification that the URB has completed is not received.\\n\\nThe reason is memory-access ordering on SMP systems. In outline form,\\nusb_kill_urb() and __usb_hcd_giveback_urb() operating concurrently on\\ndifferent CPUs perform the following actions:\\n\\nCPU 0\\t\\t\\t\\t\\tCPU 1\\n----------------------------\\t\\t---------------------------------\\nusb_kill_urb():\\t\\t\\t\\t__usb_hcd_giveback_urb():\\n ...\\t\\t\\t\\t\\t ...\\n atomic_inc(\u0026urb-\u003ereject);\\t\\t atomic_dec(\u0026urb-\u003euse_count);\\n ...\\t\\t\\t\\t\\t ...\\n wait_event(usb_kill_urb_queue,\\n\\tatomic_read(\u0026urb-\u003euse_count) == 0);\\n\\t\\t\\t\\t\\t if (atomic_read(\u0026urb-\u003ereject))\\n\\t\\t\\t\\t\\t\\twake_up(\u0026usb_kill_urb_queue);\\n\\nConfining your attention to urb-\u003ereject and urb-\u003euse_count, you can\\nsee that the overall pattern of accesses on CPU 0 is:\\n\\n\\twrite urb-\u003ereject, then read urb-\u003euse_count;\\n\\nwhereas the overall pattern of accesses on CPU 1 is:\\n\\n\\twrite urb-\u003euse_count, then read urb-\u003ereject.\\n\\nThis pattern is referred to in memory-model circles as SB (for \\\"Store\\nBuffering\\\"), and it is well known that without suitable enforcement of\\nthe desired order of accesses -- in the form of memory barriers -- it\\nis entirely possible for one or both CPUs to execute their reads ahead\\nof their writes. The end result will be that sometimes CPU 0 sees the\\nold un-decremented value of urb-\u003euse_count while CPU 1 sees the old\\nun-incremented value of urb-\u003ereject. Consequently CPU 0 ends up on\\nthe wait queue and never gets woken up, leading to the observed hang\\nin usb_kill_urb().\\n\\nThe same pattern of accesses occurs in usb_poison_urb() and the\\nfailure pathway of usb_hcd_submit_urb().\\n\\nThe problem is fixed by adding suitable memory barriers. To provide\\nproper memory-access ordering in the SB pattern, a full barrier is\\nrequired on both CPUs. The atomic_inc() and atomic_dec() accesses\\nthemselves don\u0027t provide any memory ordering, but since they are\\npresent, we can use the optimized smp_mb__after_atomic() memory\\nbarrier in the various routines to obtain the desired effect.\\n\\nThis patch adds the necessary memory barriers.\"},{\"lang\":\"es\",\"value\":\"En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: USB: core: corrige el bloqueo en usb_kill_urb agregando barreras de memoria el syzbot fuzzer ha identificado un error en el que los procesos se bloquean esperando que regrese usb_kill_urb(). Resulta que el problema no es desvincular la URB; eso funciona bien. M\u00e1s bien, el problema surge cuando no se recibe la notificaci\u00f3n de activaci\u00f3n de que la URB ha completado. El motivo son los pedidos de acceso a la memoria en los sistemas SMP. En forma resumida, usb_kill_urb() y __usb_hcd_giveback_urb() operando simult\u00e1neamente en diferentes CPU realizan las siguientes acciones: CPU 0 CPU 1 ------------------------- --- --------------------------------- usb_kill_urb(): __usb_hcd_giveback_urb(): ... ... atomic_inc(\u0026amp;urb-\u0026gt;rechazar); atomic_dec(\u0026amp;urb-\u0026gt;use_count); ... ... wait_event(usb_kill_urb_queue, atomic_read(\u0026amp;urb-\u0026gt;use_count) == 0); if (atomic_read(\u0026amp;urb-\u0026gt;reject)) wake_up(\u0026amp;usb_kill_urb_queue); Limitando su atenci\u00f3n a urb-\u0026gt;reject y urb-\u0026gt;use_count, puede ver que el patr\u00f3n general de accesos en la CPU 0 es: escribir urb-\u0026gt;reject, luego leer urb-\u0026gt;use_count; mientras que el patr\u00f3n general de accesos en la CPU 1 es: escribir urb-\u0026gt;use_count, luego leer urb-\u0026gt;reject. En los c\u00edrculos de modelos de memoria se hace referencia a este patr\u00f3n como SB (por \\\"Store Buffering\\\"), y es bien sabido que sin una aplicaci\u00f3n adecuada del orden deseado de accesos (en forma de barreras de memoria) es completamente posible que una o ambas CPU para ejecutar sus lecturas antes de sus escrituras. El resultado final ser\u00e1 que a veces la CPU 0 ve el antiguo valor no incrementado de urb-\u0026gt;use_count mientras que la CPU 1 ve el antiguo valor no incrementado de urb-\u0026gt;reject. En consecuencia, la CPU 0 termina en la cola de espera y nunca se activa, lo que provoca el bloqueo observado en usb_kill_urb(). El mismo patr\u00f3n de accesos ocurre en usb_poison_urb() y la ruta de falla de usb_hcd_submit_urb(). El problema se soluciona agregando barreras de memoria adecuadas. Para proporcionar un orden adecuado de acceso a la memoria en el patr\u00f3n SB, se requiere una barrera completa en ambas CPU. Los accesos atomic_inc() y atomic_dec() en s\u00ed no proporcionan ning\u00fan orden de memoria, pero como est\u00e1n presentes, podemos usar la barrera de memoria optimizada smp_mb__after_atomic() en las distintas rutinas para obtener el efecto deseado. Este parche agrega las barreras de memoria necesarias.\"}],\"affected\":[{\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"affectedData\":[{\"vendor\":\"Linux\",\"product\":\"Linux\",\"defaultStatus\":\"unaffected\",\"programFiles\":[\"drivers/usb/core/hcd.c\",\"drivers/usb/core/urb.c\"],\"repo\":\"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\",\"versions\":[{\"version\":\"49367d8f1d9f26482cf7089489e90f0afd0a942c\",\"lessThan\":\"5f138ef224dffd15d5e5c5b095859719e0038427\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"49367d8f1d9f26482cf7089489e90f0afd0a942c\",\"lessThan\":\"b50f5ca60475710bbc9a3af32fbfc17b1e69c2f0\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"49367d8f1d9f26482cf7089489e90f0afd0a942c\",\"lessThan\":\"546ba238535d925254e0b3f12012a5c55801e2f3\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"49367d8f1d9f26482cf7089489e90f0afd0a942c\",\"lessThan\":\"5904dfd3ddaff3bf4a41c3baf0a8e8f31ed4599b\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"49367d8f1d9f26482cf7089489e90f0afd0a942c\",\"lessThan\":\"9c61fce322ac2ef7fecf025285353570d60e41d6\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"49367d8f1d9f26482cf7089489e90f0afd0a942c\",\"lessThan\":\"e3b131e30e612ff0e32de6c1cb4f69f89db29193\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"49367d8f1d9f26482cf7089489e90f0afd0a942c\",\"lessThan\":\"9340226388c66a7e090ebb00e91ed64a753b6c26\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"49367d8f1d9f26482cf7089489e90f0afd0a942c\",\"lessThan\":\"c9a18f7c5b071dce5e6939568829d40994866ab0\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"49367d8f1d9f26482cf7089489e90f0afd0a942c\",\"lessThan\":\"26fbe9772b8c459687930511444ce443011f86bf\",\"versionType\":\"git\",\"status\":\"affected\"}]},{\"vendor\":\"Linux\",\"product\":\"Linux\",\"defaultStatus\":\"affected\",\"programFiles\":[\"drivers/usb/core/hcd.c\",\"drivers/usb/core/urb.c\"],\"repo\":\"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\",\"versions\":[{\"version\":\"2.6.29\",\"status\":\"affected\"},{\"version\":\"0\",\"lessThan\":\"2.6.29\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"4.4.302\",\"lessThanOrEqual\":\"4.4.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"4.9.300\",\"lessThanOrEqual\":\"4.9.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"4.14.265\",\"lessThanOrEqual\":\"4.14.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"4.19.228\",\"lessThanOrEqual\":\"4.19.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"5.4.176\",\"lessThanOrEqual\":\"5.4.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"5.10.96\",\"lessThanOrEqual\":\"5.10.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"5.15.19\",\"lessThanOrEqual\":\"5.15.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"5.16.5\",\"lessThanOrEqual\":\"5.16.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"5.17\",\"lessThanOrEqual\":\"*\",\"versionType\":\"original_commit_for_fix\",\"status\":\"unaffected\"}]}]}],\"metrics\":{\"cvssMetricV31\":[{\"source\":\"nvd@nist.gov\",\"type\":\"Primary\",\"cvssData\":{\"version\":\"3.1\",\"vectorString\":\"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H\",\"baseScore\":7.1,\"baseSeverity\":\"HIGH\",\"attackVector\":\"LOCAL\",\"attackComplexity\":\"LOW\",\"privilegesRequired\":\"LOW\",\"userInteraction\":\"NONE\",\"scope\":\"UNCHANGED\",\"confidentialityImpact\":\"HIGH\",\"integrityImpact\":\"NONE\",\"availabilityImpact\":\"HIGH\"},\"exploitabilityScore\":1.8,\"impactScore\":5.2}],\"ssvcV203\":[{\"source\":\"134c704f-9b21-4f2e-91b3-4a467353bcc0\",\"ssvcData\":{\"timestamp\":\"2024-06-20T14:49:44.326446Z\",\"id\":\"CVE-2022-48760\",\"options\":[{\"exploitation\":\"none\"},{\"automatable\":\"no\"},{\"technicalImpact\":\"partial\"}],\"role\":\"CISA Coordinator\",\"version\":\"2.0.3\"}}]},\"weaknesses\":[{\"source\":\"nvd@nist.gov\",\"type\":\"Primary\",\"description\":[{\"lang\":\"en\",\"value\":\"CWE-667\"}]}],\"configurations\":[{\"nodes\":[{\"operator\":\"OR\",\"negate\":false,\"cpeMatch\":[{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionEndExcluding\":\"4.4.302\",\"matchCriteriaId\":\"09609993-CA3F-47E6-ABB6-BF512D8AFF65\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"4.5\",\"versionEndExcluding\":\"4.9.300\",\"matchCriteriaId\":\"A3BD638C-9597-4C2B-8024-32F57E1B53E3\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"4.10\",\"versionEndExcluding\":\"4.14.265\",\"matchCriteriaId\":\"4F849B5B-93E9-438A-AE05-0380EC168436\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"4.15\",\"versionEndExcluding\":\"4.19.228\",\"matchCriteriaId\":\"87288F16-8DE4-4680-95D9-8601B47620D7\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"4.20\",\"versionEndExcluding\":\"5.4.176\",\"matchCriteriaId\":\"581D4C61-D3FC-4DB2-85E3-EE596EEBA89E\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"5.5\",\"versionEndExcluding\":\"5.10.96\",\"matchCriteriaId\":\"27A6621A-A196-4220-957F-334B9124E477\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"5.11\",\"versionEndExcluding\":\"5.15.19\",\"matchCriteriaId\":\"DF69DD7C-FD57-4914-ABB0-FAEF87B0289D\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"5.16\",\"versionEndExcluding\":\"5.16.5\",\"matchCriteriaId\":\"1AD9E77E-B27E-450C-8FD8-B64EC5FB002D\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:5.17:rc1:*:*:*:*:*:*\",\"matchCriteriaId\":\"7BD5F8D9-54FA-4CB0-B4F0-CB0471FDDB2D\"}]}]}],\"references\":[{\"url\":\"https://git.kernel.org/stable/c/26fbe9772b8c459687930511444ce443011f86bf\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/546ba238535d925254e0b3f12012a5c55801e2f3\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/5904dfd3ddaff3bf4a41c3baf0a8e8f31ed4599b\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/5f138ef224dffd15d5e5c5b095859719e0038427\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/9340226388c66a7e090ebb00e91ed64a753b6c26\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/9c61fce322ac2ef7fecf025285353570d60e41d6\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/b50f5ca60475710bbc9a3af32fbfc17b1e69c2f0\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/c9a18f7c5b071dce5e6939568829d40994866ab0\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/e3b131e30e612ff0e32de6c1cb4f69f89db29193\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/26fbe9772b8c459687930511444ce443011f86bf\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/546ba238535d925254e0b3f12012a5c55801e2f3\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/5904dfd3ddaff3bf4a41c3baf0a8e8f31ed4599b\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/5f138ef224dffd15d5e5c5b095859719e0038427\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/9340226388c66a7e090ebb00e91ed64a753b6c26\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/9c61fce322ac2ef7fecf025285353570d60e41d6\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/b50f5ca60475710bbc9a3af32fbfc17b1e69c2f0\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/c9a18f7c5b071dce5e6939568829d40994866ab0\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/e3b131e30e612ff0e32de6c1cb4f69f89db29193\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\",\"tags\":[\"Patch\"]}]}}",
"redhat_vex": {
"aggregate_severity": "Low",
"current_release_date": "2026-06-28T11:40:37+00:00",
"cve": "CVE-2022-48760",
"id": "CVE-2022-48760",
"initial_release_date": "2022-01-01T00:00:00+00:00",
"product_status:fixed": "150",
"product_status:known_affected": "150",
"source": "Red Hat CSAF VEX",
"status": "final",
"title": "kernel: USB: core: Fix hang in usb_kill_urb by adding memory barriers",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2022/cve-2022-48760.json",
"version": "3"
},
"suse_vex": {
"aggregate_severity": "moderate",
"current_release_date": "2026-09-11T02:34:13Z",
"cve": "CVE-2022-48760",
"id": "CVE-2022-48760",
"initial_release_date": "2024-06-22T04:08:55Z",
"product_status:known_affected": "423",
"product_status:known_not_affected": "69",
"product_status:recommended": "644",
"source": "SUSE CSAF VEX",
"status": "interim",
"title": "SUSE CVE CVE-2022-48760",
"url": "https://ftp.suse.com/pub/projects/security/csaf-vex/cve-2022-48760.json",
"version": "67"
},
"vulnrichment": {
"containers": "{\"adp\": [{\"title\": \"CVE Program Container\", \"references\": [{\"url\": \"https://git.kernel.org/stable/c/5f138ef224dffd15d5e5c5b095859719e0038427\", \"tags\": [\"x_transferred\"]}, {\"url\": \"https://git.kernel.org/stable/c/b50f5ca60475710bbc9a3af32fbfc17b1e69c2f0\", \"tags\": [\"x_transferred\"]}, {\"url\": \"https://git.kernel.org/stable/c/546ba238535d925254e0b3f12012a5c55801e2f3\", \"tags\": [\"x_transferred\"]}, {\"url\": \"https://git.kernel.org/stable/c/5904dfd3ddaff3bf4a41c3baf0a8e8f31ed4599b\", \"tags\": [\"x_transferred\"]}, {\"url\": \"https://git.kernel.org/stable/c/9c61fce322ac2ef7fecf025285353570d60e41d6\", \"tags\": [\"x_transferred\"]}, {\"url\": \"https://git.kernel.org/stable/c/e3b131e30e612ff0e32de6c1cb4f69f89db29193\", \"tags\": [\"x_transferred\"]}, {\"url\": \"https://git.kernel.org/stable/c/9340226388c66a7e090ebb00e91ed64a753b6c26\", \"tags\": [\"x_transferred\"]}, {\"url\": \"https://git.kernel.org/stable/c/c9a18f7c5b071dce5e6939568829d40994866ab0\", \"tags\": [\"x_transferred\"]}, {\"url\": \"https://git.kernel.org/stable/c/26fbe9772b8c459687930511444ce443011f86bf\", \"tags\": [\"x_transferred\"]}], \"providerMetadata\": {\"orgId\": \"af854a3a-2127-422b-91ae-364da2661108\", \"shortName\": \"CVE\", \"dateUpdated\": \"2024-08-03T15:25:01.565Z\"}}, {\"title\": \"CISA ADP Vulnrichment\", \"metrics\": [{\"other\": {\"type\": \"ssvc\", \"content\": {\"id\": \"CVE-2022-48760\", \"role\": \"CISA Coordinator\", \"options\": [{\"Exploitation\": \"none\"}, {\"Automatable\": \"no\"}, {\"Technical Impact\": \"partial\"}], \"version\": \"2.0.3\", \"timestamp\": \"2024-06-20T14:49:44.326446Z\"}}}], \"providerMetadata\": {\"orgId\": \"134c704f-9b21-4f2e-91b3-4a467353bcc0\", \"shortName\": \"CISA-ADP\", \"dateUpdated\": \"2024-06-20T14:49:54.279Z\"}}], \"cna\": {\"title\": \"USB: core: Fix hang in usb_kill_urb by adding memory barriers\", \"affected\": [{\"repo\": \"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\", \"vendor\": \"Linux\", \"product\": \"Linux\", \"versions\": [{\"status\": \"affected\", \"version\": \"49367d8f1d9f26482cf7089489e90f0afd0a942c\", \"lessThan\": \"5f138ef224dffd15d5e5c5b095859719e0038427\", \"versionType\": \"git\"}, {\"status\": \"affected\", \"version\": \"49367d8f1d9f26482cf7089489e90f0afd0a942c\", \"lessThan\": \"b50f5ca60475710bbc9a3af32fbfc17b1e69c2f0\", \"versionType\": \"git\"}, {\"status\": \"affected\", \"version\": \"49367d8f1d9f26482cf7089489e90f0afd0a942c\", \"lessThan\": \"546ba238535d925254e0b3f12012a5c55801e2f3\", \"versionType\": \"git\"}, {\"status\": \"affected\", \"version\": \"49367d8f1d9f26482cf7089489e90f0afd0a942c\", \"lessThan\": \"5904dfd3ddaff3bf4a41c3baf0a8e8f31ed4599b\", \"versionType\": \"git\"}, {\"status\": \"affected\", \"version\": \"49367d8f1d9f26482cf7089489e90f0afd0a942c\", \"lessThan\": \"9c61fce322ac2ef7fecf025285353570d60e41d6\", \"versionType\": \"git\"}, {\"status\": \"affected\", \"version\": \"49367d8f1d9f26482cf7089489e90f0afd0a942c\", \"lessThan\": \"e3b131e30e612ff0e32de6c1cb4f69f89db29193\", \"versionType\": \"git\"}, {\"status\": \"affected\", \"version\": \"49367d8f1d9f26482cf7089489e90f0afd0a942c\", \"lessThan\": \"9340226388c66a7e090ebb00e91ed64a753b6c26\", \"versionType\": \"git\"}, {\"status\": \"affected\", \"version\": \"49367d8f1d9f26482cf7089489e90f0afd0a942c\", \"lessThan\": \"c9a18f7c5b071dce5e6939568829d40994866ab0\", \"versionType\": \"git\"}, {\"status\": \"affected\", \"version\": \"49367d8f1d9f26482cf7089489e90f0afd0a942c\", \"lessThan\": \"26fbe9772b8c459687930511444ce443011f86bf\", \"versionType\": \"git\"}], \"programFiles\": [\"drivers/usb/core/hcd.c\", \"drivers/usb/core/urb.c\"], \"defaultStatus\": \"unaffected\"}, {\"repo\": \"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\", \"vendor\": \"Linux\", \"product\": \"Linux\", \"versions\": [{\"status\": \"affected\", \"version\": \"2.6.29\"}, {\"status\": \"unaffected\", \"version\": \"0\", \"lessThan\": \"2.6.29\", \"versionType\": \"semver\"}, {\"status\": \"unaffected\", \"version\": \"4.4.302\", \"versionType\": \"semver\", \"lessThanOrEqual\": \"4.4.*\"}, {\"status\": \"unaffected\", \"version\": \"4.9.300\", \"versionType\": \"semver\", \"lessThanOrEqual\": \"4.9.*\"}, {\"status\": \"unaffected\", \"version\": \"4.14.265\", \"versionType\": \"semver\", \"lessThanOrEqual\": \"4.14.*\"}, {\"status\": \"unaffected\", \"version\": \"4.19.228\", \"versionType\": \"semver\", \"lessThanOrEqual\": \"4.19.*\"}, {\"status\": \"unaffected\", \"version\": \"5.4.176\", \"versionType\": \"semver\", \"lessThanOrEqual\": \"5.4.*\"}, {\"status\": \"unaffected\", \"version\": \"5.10.96\", \"versionType\": \"semver\", \"lessThanOrEqual\": \"5.10.*\"}, {\"status\": \"unaffected\", \"version\": \"5.15.19\", \"versionType\": \"semver\", \"lessThanOrEqual\": \"5.15.*\"}, {\"status\": \"unaffected\", \"version\": \"5.16.5\", \"versionType\": \"semver\", \"lessThanOrEqual\": \"5.16.*\"}, {\"status\": \"unaffected\", \"version\": \"5.17\", \"versionType\": \"original_commit_for_fix\", \"lessThanOrEqual\": \"*\"}], \"programFiles\": [\"drivers/usb/core/hcd.c\", \"drivers/usb/core/urb.c\"], \"defaultStatus\": \"affected\"}], \"references\": [{\"url\": \"https://git.kernel.org/stable/c/5f138ef224dffd15d5e5c5b095859719e0038427\"}, {\"url\": \"https://git.kernel.org/stable/c/b50f5ca60475710bbc9a3af32fbfc17b1e69c2f0\"}, {\"url\": \"https://git.kernel.org/stable/c/546ba238535d925254e0b3f12012a5c55801e2f3\"}, {\"url\": \"https://git.kernel.org/stable/c/5904dfd3ddaff3bf4a41c3baf0a8e8f31ed4599b\"}, {\"url\": \"https://git.kernel.org/stable/c/9c61fce322ac2ef7fecf025285353570d60e41d6\"}, {\"url\": \"https://git.kernel.org/stable/c/e3b131e30e612ff0e32de6c1cb4f69f89db29193\"}, {\"url\": \"https://git.kernel.org/stable/c/9340226388c66a7e090ebb00e91ed64a753b6c26\"}, {\"url\": \"https://git.kernel.org/stable/c/c9a18f7c5b071dce5e6939568829d40994866ab0\"}, {\"url\": \"https://git.kernel.org/stable/c/26fbe9772b8c459687930511444ce443011f86bf\"}], \"x_generator\": {\"engine\": \"bippy-1.2.0\"}, \"descriptions\": [{\"lang\": \"en\", \"value\": \"In the Linux kernel, the following vulnerability has been resolved:\\n\\nUSB: core: Fix hang in usb_kill_urb by adding memory barriers\\n\\nThe syzbot fuzzer has identified a bug in which processes hang waiting\\nfor usb_kill_urb() to return. It turns out the issue is not unlinking\\nthe URB; that works just fine. Rather, the problem arises when the\\nwakeup notification that the URB has completed is not received.\\n\\nThe reason is memory-access ordering on SMP systems. In outline form,\\nusb_kill_urb() and __usb_hcd_giveback_urb() operating concurrently on\\ndifferent CPUs perform the following actions:\\n\\nCPU 0\\t\\t\\t\\t\\tCPU 1\\n----------------------------\\t\\t---------------------------------\\nusb_kill_urb():\\t\\t\\t\\t__usb_hcd_giveback_urb():\\n ...\\t\\t\\t\\t\\t ...\\n atomic_inc(\u0026urb-\u003ereject);\\t\\t atomic_dec(\u0026urb-\u003euse_count);\\n ...\\t\\t\\t\\t\\t ...\\n wait_event(usb_kill_urb_queue,\\n\\tatomic_read(\u0026urb-\u003euse_count) == 0);\\n\\t\\t\\t\\t\\t if (atomic_read(\u0026urb-\u003ereject))\\n\\t\\t\\t\\t\\t\\twake_up(\u0026usb_kill_urb_queue);\\n\\nConfining your attention to urb-\u003ereject and urb-\u003euse_count, you can\\nsee that the overall pattern of accesses on CPU 0 is:\\n\\n\\twrite urb-\u003ereject, then read urb-\u003euse_count;\\n\\nwhereas the overall pattern of accesses on CPU 1 is:\\n\\n\\twrite urb-\u003euse_count, then read urb-\u003ereject.\\n\\nThis pattern is referred to in memory-model circles as SB (for \\\"Store\\nBuffering\\\"), and it is well known that without suitable enforcement of\\nthe desired order of accesses -- in the form of memory barriers -- it\\nis entirely possible for one or both CPUs to execute their reads ahead\\nof their writes. The end result will be that sometimes CPU 0 sees the\\nold un-decremented value of urb-\u003euse_count while CPU 1 sees the old\\nun-incremented value of urb-\u003ereject. Consequently CPU 0 ends up on\\nthe wait queue and never gets woken up, leading to the observed hang\\nin usb_kill_urb().\\n\\nThe same pattern of accesses occurs in usb_poison_urb() and the\\nfailure pathway of usb_hcd_submit_urb().\\n\\nThe problem is fixed by adding suitable memory barriers. To provide\\nproper memory-access ordering in the SB pattern, a full barrier is\\nrequired on both CPUs. The atomic_inc() and atomic_dec() accesses\\nthemselves don\u0027t provide any memory ordering, but since they are\\npresent, we can use the optimized smp_mb__after_atomic() memory\\nbarrier in the various routines to obtain the desired effect.\\n\\nThis patch adds the necessary memory barriers.\"}], \"cpeApplicability\": [{\"nodes\": [{\"negate\": false, \"cpeMatch\": [{\"criteria\": \"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\", \"vulnerable\": true, \"versionEndExcluding\": \"4.4.302\", \"versionStartIncluding\": \"2.6.29\"}, {\"criteria\": \"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\", \"vulnerable\": true, \"versionEndExcluding\": \"4.9.300\", \"versionStartIncluding\": \"2.6.29\"}, {\"criteria\": \"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\", \"vulnerable\": true, \"versionEndExcluding\": \"4.14.265\", \"versionStartIncluding\": \"2.6.29\"}, {\"criteria\": \"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\", \"vulnerable\": true, \"versionEndExcluding\": \"4.19.228\", \"versionStartIncluding\": \"2.6.29\"}, {\"criteria\": \"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\", \"vulnerable\": true, \"versionEndExcluding\": \"5.4.176\", \"versionStartIncluding\": \"2.6.29\"}, {\"criteria\": \"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\", \"vulnerable\": true, \"versionEndExcluding\": \"5.10.96\", \"versionStartIncluding\": \"2.6.29\"}, {\"criteria\": \"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\", \"vulnerable\": true, \"versionEndExcluding\": \"5.15.19\", \"versionStartIncluding\": \"2.6.29\"}, {\"criteria\": \"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\", \"vulnerable\": true, \"versionEndExcluding\": \"5.16.5\", \"versionStartIncluding\": \"2.6.29\"}, {\"criteria\": \"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\", \"vulnerable\": true, \"versionEndExcluding\": \"5.17\", \"versionStartIncluding\": \"2.6.29\"}], \"operator\": \"OR\"}]}], \"providerMetadata\": {\"orgId\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\", \"shortName\": \"Linux\", \"dateUpdated\": \"2025-12-23T13:20:18.737Z\"}}}",
"cveMetadata": "{\"cveId\": \"CVE-2022-48760\", \"state\": \"PUBLISHED\", \"dateUpdated\": \"2025-12-23T13:20:18.737Z\", \"dateReserved\": \"2024-06-20T11:09:39.059Z\", \"assignerOrgId\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\", \"datePublished\": \"2024-06-20T11:13:38.532Z\", \"assignerShortName\": \"Linux\"}",
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
}
}
Loading…
Loading…
Experimental. This forecast is provided for visualization only and may change without notice. Do not use it for operational decisions.
Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Loading…
The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the
vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base
model, served locally by ML-Gateway.
They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Loading…
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.
Loading…