fkie_cve-2022-48760
Vulnerability from fkie_nvd
Published
2024-06-20 12:15
Modified
2025-09-17 16:49
Severity ?
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.
References
Impacted products
| Vendor | Product | Version | |
|---|---|---|---|
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | 5.17 |
{
"configurations": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "09609993-CA3F-47E6-ABB6-BF512D8AFF65",
"versionEndExcluding": "4.4.302",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "A3BD638C-9597-4C2B-8024-32F57E1B53E3",
"versionEndExcluding": "4.9.300",
"versionStartIncluding": "4.5",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "4F849B5B-93E9-438A-AE05-0380EC168436",
"versionEndExcluding": "4.14.265",
"versionStartIncluding": "4.10",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "87288F16-8DE4-4680-95D9-8601B47620D7",
"versionEndExcluding": "4.19.228",
"versionStartIncluding": "4.15",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "581D4C61-D3FC-4DB2-85E3-EE596EEBA89E",
"versionEndExcluding": "5.4.176",
"versionStartIncluding": "4.20",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "27A6621A-A196-4220-957F-334B9124E477",
"versionEndExcluding": "5.10.96",
"versionStartIncluding": "5.5",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "DF69DD7C-FD57-4914-ABB0-FAEF87B0289D",
"versionEndExcluding": "5.15.19",
"versionStartIncluding": "5.11",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "1AD9E77E-B27E-450C-8FD8-B64EC5FB002D",
"versionEndExcluding": "5.16.5",
"versionStartIncluding": "5.16",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:5.17:rc1:*:*:*:*:*:*",
"matchCriteriaId": "7BD5F8D9-54FA-4CB0-B4F0-CB0471FDDB2D",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"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."
}
],
"id": "CVE-2022-48760",
"lastModified": "2025-09-17T16:49:52.623",
"metrics": {
"cvssMetricV31": [
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 7.1,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "NONE",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H",
"version": "3.1"
},
"exploitabilityScore": 1.8,
"impactScore": 5.2,
"source": "nvd@nist.gov",
"type": "Primary"
}
]
},
"published": "2024-06-20T12:15:14.110",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"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": "af854a3a-2127-422b-91ae-364da2661108",
"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"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Analyzed",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "CWE-667"
}
],
"source": "nvd@nist.gov",
"type": "Primary"
}
]
}
Loading…
Loading…
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
- Confirmed: The vulnerability is confirmed from an analyst perspective.
- Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
- Patched: This vulnerability was successfully patched by the user reporting the sighting.
- Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
- Not confirmed: The user expresses doubt about the veracity of the vulnerability.
- Not patched: This vulnerability was not successfully patched by the user reporting the sighting.
Loading…