{"dataType": "CVE_RECORD", "dataVersion": "5.1", "cveMetadata": {"cveId": "CVE-2022-48760", "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "state": "PUBLISHED", "assignerShortName": "Linux", "dateReserved": "2024-06-20T11:09:39.059Z", "datePublished": "2024-06-20T11:13:38.532Z", "dateUpdated": "2024-08-03T15:25:01.565Z"}, "containers": {"cna": {"providerMetadata": {"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "shortName": "Linux", "dateUpdated": "2024-06-20T11:14:54.367Z"}, "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(&urb->reject);\t\t atomic_dec(&urb->use_count);\n ...\t\t\t\t\t ...\n wait_event(usb_kill_urb_queue,\n\tatomic_read(&urb->use_count) == 0);\n\t\t\t\t\t if (atomic_read(&urb->reject))\n\t\t\t\t\t\twake_up(&usb_kill_urb_queue);\n\nConfining your attention to urb->reject and urb->use_count, you can\nsee that the overall pattern of accesses on CPU 0 is:\n\n\twrite urb->reject, then read urb->use_count;\n\nwhereas the overall pattern of accesses on CPU 1 is:\n\n\twrite urb->use_count, then read urb->reject.\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->use_count while CPU 1 sees the old\nun-incremented value of urb->reject. 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't 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."}], "affected": [{"product": "Linux", "vendor": "Linux", "defaultStatus": "unaffected", "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "programFiles": ["drivers/usb/core/hcd.c", "drivers/usb/core/urb.c"], "versions": [{"version": "1da177e4c3f4", "lessThan": "5f138ef224df", "status": "affected", "versionType": "git"}, {"version": "1da177e4c3f4", "lessThan": "b50f5ca60475", "status": "affected", "versionType": "git"}, {"version": "1da177e4c3f4", "lessThan": "546ba238535d", "status": "affected", "versionType": "git"}, {"version": "1da177e4c3f4", "lessThan": "5904dfd3ddaf", "status": "affected", "versionType": "git"}, {"version": "1da177e4c3f4", "lessThan": "9c61fce322ac", "status": "affected", "versionType": "git"}, {"version": "1da177e4c3f4", "lessThan": "e3b131e30e61", "status": "affected", "versionType": "git"}, {"version": "1da177e4c3f4", "lessThan": "9340226388c6", "status": "affected", "versionType": "git"}, {"version": "1da177e4c3f4", "lessThan": "c9a18f7c5b07", "status": "affected", "versionType": "git"}, {"version": "1da177e4c3f4", "lessThan": "26fbe9772b8c", "status": "affected", "versionType": "git"}]}, {"product": "Linux", "vendor": "Linux", "defaultStatus": "affected", "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "programFiles": ["drivers/usb/core/hcd.c", "drivers/usb/core/urb.c"], "versions": [{"version": "4.4.302", "lessThanOrEqual": "4.4.*", "status": "unaffected", "versionType": "custom"}, {"version": "4.9.300", "lessThanOrEqual": "4.9.*", "status": "unaffected", "versionType": "custom"}, {"version": "4.14.265", "lessThanOrEqual": "4.14.*", "status": "unaffected", "versionType": "custom"}, {"version": "4.19.228", "lessThanOrEqual": "4.19.*", "status": "unaffected", "versionType": "custom"}, {"version": "5.4.176", "lessThanOrEqual": "5.4.*", "status": "unaffected", "versionType": "custom"}, {"version": "5.10.96", "lessThanOrEqual": "5.10.*", "status": "unaffected", "versionType": "custom"}, {"version": "5.15.19", "lessThanOrEqual": "5.15.*", "status": "unaffected", "versionType": "custom"}, {"version": "5.16.5", "lessThanOrEqual": "5.16.*", "status": "unaffected", "versionType": "custom"}, {"version": "5.17", "lessThanOrEqual": "*", "status": "unaffected", "versionType": "original_commit_for_fix"}]}], "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-7d53e8ef8be4"}}, "adp": [{"metrics": [{"other": {"type": "ssvc", "content": {"timestamp": "2024-06-20T14:49:44.326446Z", "id": "CVE-2022-48760", "options": [{"Exploitation": "none"}, {"Automatable": "no"}, {"Technical Impact": "partial"}], "role": "CISA Coordinator", "version": "2.0.3"}}}], "title": "CISA ADP Vulnrichment", "providerMetadata": {"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "shortName": "CISA-ADP", "dateUpdated": "2024-06-20T14:50:00.838Z"}}, {"providerMetadata": {"orgId": "af854a3a-2127-422b-91ae-364da2661108", "shortName": "CVE", "dateUpdated": "2024-08-03T15:25:01.565Z"}, "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"]}]}]}}

{"dataType": "CVE_RECORD", "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": "1da177e4c3f4", "lessThan": "5f138ef224df", "versionType": "git"}, {"status": "affected", "version": "1da177e4c3f4", "lessThan": "b50f5ca60475", "versionType": "git"}, {"status": "affected", "version": "1da177e4c3f4", "lessThan": "546ba238535d", "versionType": "git"}, {"status": "affected", "version": "1da177e4c3f4", "lessThan": "5904dfd3ddaf", "versionType": "git"}, {"status": "affected", "version": "1da177e4c3f4", "lessThan": "9c61fce322ac", "versionType": "git"}, {"status": "affected", "version": "1da177e4c3f4", "lessThan": "e3b131e30e61", "versionType": "git"}, {"status": "affected", "version": "1da177e4c3f4", "lessThan": "9340226388c6", "versionType": "git"}, {"status": "affected", "version": "1da177e4c3f4", "lessThan": "c9a18f7c5b07", "versionType": "git"}, {"status": "affected", "version": "1da177e4c3f4", "lessThan": "26fbe9772b8c", "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": "unaffected", "version": "4.4.302", "versionType": "custom", "lessThanOrEqual": "4.4.*"}, {"status": "unaffected", "version": "4.9.300", "versionType": "custom", "lessThanOrEqual": "4.9.*"}, {"status": "unaffected", "version": "4.14.265", "versionType": "custom", "lessThanOrEqual": "4.14.*"}, {"status": "unaffected", "version": "4.19.228", "versionType": "custom", "lessThanOrEqual": "4.19.*"}, {"status": "unaffected", "version": "5.4.176", "versionType": "custom", "lessThanOrEqual": "5.4.*"}, {"status": "unaffected", "version": "5.10.96", "versionType": "custom", "lessThanOrEqual": "5.10.*"}, {"status": "unaffected", "version": "5.15.19", "versionType": "custom", "lessThanOrEqual": "5.15.*"}, {"status": "unaffected", "version": "5.16.5", "versionType": "custom", "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-7d53e8ef8be4"}, "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(&urb->reject);\t\t atomic_dec(&urb->use_count);\n ...\t\t\t\t\t ...\n wait_event(usb_kill_urb_queue,\n\tatomic_read(&urb->use_count) == 0);\n\t\t\t\t\t if (atomic_read(&urb->reject))\n\t\t\t\t\t\twake_up(&usb_kill_urb_queue);\n\nConfining your attention to urb->reject and urb->use_count, you can\nsee that the overall pattern of accesses on CPU 0 is:\n\n\twrite urb->reject, then read urb->use_count;\n\nwhereas the overall pattern of accesses on CPU 1 is:\n\n\twrite urb->use_count, then read urb->reject.\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->use_count while CPU 1 sees the old\nun-incremented value of urb->reject. 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't 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": {"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "shortName": "Linux", "dateUpdated": "2024-06-20T11:14:54.367Z"}}}, "cveMetadata": {"cveId": "CVE-2022-48760", "state": "PUBLISHED", "dateUpdated": "2024-08-03T15:25:01.565Z", "dateReserved": "2024-06-20T11:09:39.059Z", "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "datePublished": "2024-06-20T11:13:38.532Z", "assignerShortName": "Linux"}, "dataVersion": "5.1"}

{"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(&urb->reject);\t\t atomic_dec(&urb->use_count);\n ...\t\t\t\t\t ...\n wait_event(usb_kill_urb_queue,\n\tatomic_read(&urb->use_count) == 0);\n\t\t\t\t\t if (atomic_read(&urb->reject))\n\t\t\t\t\t\twake_up(&usb_kill_urb_queue);\n\nConfining your attention to urb->reject and urb->use_count, you can\nsee that the overall pattern of accesses on CPU 0 is:\n\n\twrite urb->reject, then read urb->use_count;\n\nwhereas the overall pattern of accesses on CPU 1 is:\n\n\twrite urb->use_count, then read urb->reject.\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->use_count while CPU 1 sees the old\nun-incremented value of urb->reject. 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't 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(&urb->rechazar); 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); Limitando su atenci\u00f3n a urb->reject y urb->use_count, puede ver que el patr\u00f3n general de accesos en la CPU 0 es: escribir urb->reject, luego leer urb->use_count; mientras que el patr\u00f3n general de accesos en la CPU 1 es: escribir urb->use_count, luego leer urb->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->use_count mientras que la CPU 1 ve el antiguo valor no incrementado de urb->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-06-20T12:43:25.663", "metrics": {}, "published": "2024-06-20T12:15:14.110", "references": [{"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "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"}], "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "vulnStatus": "Awaiting Analysis"}

{"affected_release": [{"advisory": "RHSA-2024:7001", "cpe": "cpe:/a:redhat:enterprise_linux:8::nfv", "package": "kernel-rt-0:4.18.0-553.22.1.rt7.363.el8_10", "product_name": "Red Hat Enterprise Linux 8", "release_date": "2024-09-24T00:00:00Z"}, {"advisory": "RHSA-2024:7000", "cpe": "cpe:/o:redhat:enterprise_linux:8", "package": "kernel-0:4.18.0-553.22.1.el8_10", "product_name": "Red Hat Enterprise Linux 8", "release_date": "2024-09-24T00:00:00Z"}], "bugzilla": {"description": "kernel: USB: core: Fix hang in usb_kill_urb by adding memory barriers", "id": "2293377", "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2293377"}, "csaw": false, "cvss3": {"cvss3_base_score": "4.1", "cvss3_scoring_vector": "CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:H", "status": "verified"}, "cwe": "CWE-820", "details": ["In the Linux kernel, the following vulnerability has been resolved:\nUSB: core: Fix hang in usb_kill_urb by adding memory barriers\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.\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:\nCPU 0CPU 1\n-------------------------------------------------------------\nusb_kill_urb():__usb_hcd_giveback_urb():\n... ...\natomic_inc(&urb->reject); atomic_dec(&urb->use_count);\n... ...\nwait_event(usb_kill_urb_queue,\natomic_read(&urb->use_count) == 0);\nif (atomic_read(&urb->reject))\nwake_up(&usb_kill_urb_queue);\nConfining your attention to urb->reject and urb->use_count, you can\nsee that the overall pattern of accesses on CPU 0 is:\nwrite urb->reject, then read urb->use_count;\nwhereas the overall pattern of accesses on CPU 1 is:\nwrite urb->use_count, then read urb->reject.\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->use_count while CPU 1 sees the old\nun-incremented value of urb->reject. Consequently CPU 0 ends up on\nthe wait queue and never gets woken up, leading to the observed hang\nin usb_kill_urb().\nThe same pattern of accesses occurs in usb_poison_urb() and the\nfailure pathway of usb_hcd_submit_urb().\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't 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.\nThis patch adds the necessary memory barriers."], "name": "CVE-2022-48760", "package_state": [{"cpe": "cpe:/o:redhat:enterprise_linux:6", "fix_state": "Out of support scope", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 6"}, {"cpe": "cpe:/o:redhat:enterprise_linux:7", "fix_state": "Out of support scope", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 7"}, {"cpe": "cpe:/o:redhat:enterprise_linux:7", "fix_state": "Out of support scope", "package_name": "kernel-rt", "product_name": "Red Hat Enterprise Linux 7"}, {"cpe": "cpe:/o:redhat:enterprise_linux:9", "fix_state": "Affected", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 9"}, {"cpe": "cpe:/o:redhat:enterprise_linux:9", "fix_state": "Affected", "package_name": "kernel-rt", "product_name": "Red Hat Enterprise Linux 9"}], "public_date": "2024-06-20T00:00:00Z", "references": ["https://www.cve.org/CVERecord?id=CVE-2022-48760\nhttps://nvd.nist.gov/vuln/detail/CVE-2022-48760\nhttps://lore.kernel.org/linux-cve-announce/2024062008-CVE-2022-48760-b80e@gregkh/T"], "threat_severity": "Low", "upstream_fix": "kernel 4.4.302, kernel 4.9.300, kernel 4.14.265, kernel 4.19.228, kernel 5.4.176, kernel 5.10.96, kernel 5.15.19, kernel 5.16.5, kernel 5.17"}