{"id":"CVE-2022-48760","summary":"USB: core: Fix hang in usb_kill_urb by adding memory barriers","details":"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-\u003ereject);\t\t  atomic_dec(&urb-\u003euse_count);\n  ...\t\t\t\t\t  ...\n  wait_event(usb_kill_urb_queue,\n\tatomic_read(&urb-\u003euse_count) == 0);\n\t\t\t\t\t  if (atomic_read(&urb-\u003ereject))\n\t\t\t\t\t\twake_up(&usb_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'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.","modified":"2026-05-28T03:53:56.303392607Z","published":"2024-06-20T11:13:38.532Z","related":["ALSA-2024:7000","ALSA-2024:7001","SUSE-SU-2024:2360-1","SUSE-SU-2024:2362-1","SUSE-SU-2024:2365-1","SUSE-SU-2024:2372-1","SUSE-SU-2024:2381-1","SUSE-SU-2024:2384-1","SUSE-SU-2024:2394-1","SUSE-SU-2024:2561-1","SUSE-SU-2024:2902-1","SUSE-SU-2024:2929-1","SUSE-SU-2024:2939-1"],"database_specific":{"osv_generated_from":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2022/48xxx/CVE-2022-48760.json","cna_assigner":"Linux"},"references":[{"type":"WEB","url":"https://git.kernel.org/stable/c/26fbe9772b8c459687930511444ce443011f86bf"},{"type":"WEB","url":"https://git.kernel.org/stable/c/546ba238535d925254e0b3f12012a5c55801e2f3"},{"type":"WEB","url":"https://git.kernel.org/stable/c/5904dfd3ddaff3bf4a41c3baf0a8e8f31ed4599b"},{"type":"WEB","url":"https://git.kernel.org/stable/c/5f138ef224dffd15d5e5c5b095859719e0038427"},{"type":"WEB","url":"https://git.kernel.org/stable/c/9340226388c66a7e090ebb00e91ed64a753b6c26"},{"type":"WEB","url":"https://git.kernel.org/stable/c/9c61fce322ac2ef7fecf025285353570d60e41d6"},{"type":"WEB","url":"https://git.kernel.org/stable/c/b50f5ca60475710bbc9a3af32fbfc17b1e69c2f0"},{"type":"WEB","url":"https://git.kernel.org/stable/c/c9a18f7c5b071dce5e6939568829d40994866ab0"},{"type":"WEB","url":"https://git.kernel.org/stable/c/e3b131e30e612ff0e32de6c1cb4f69f89db29193"},{"type":"ADVISORY","url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2022/48xxx/CVE-2022-48760.json"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-48760"},{"type":"PACKAGE","url":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git"}],"affected":[{"ranges":[{"type":"GIT","repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.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/osv-test-cve-osv-conversion/osv-output/CVE-2022-48760.json"}},{"package":{"name":"Kernel","ecosystem":"Linux"},"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"}]}],"database_specific":{"source":"https://storage.googleapis.com/osv-test-cve-osv-conversion/osv-output/CVE-2022-48760.json"}}],"schema_version":"1.7.5"}