| From bippy-5f407fcff5a0 Mon Sep 17 00:00:00 2001 |
| From: Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
| To: <linux-cve-announce@vger.kernel.org> |
| Reply-to: <cve@kernel.org>, <linux-kernel@vger.kernel.org> |
| Subject: CVE-2022-48760: USB: core: Fix hang in usb_kill_urb by adding memory barriers |
| |
| Description |
| =========== |
| |
| 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. |
| |
| The Linux kernel CVE team has assigned CVE-2022-48760 to this issue. |
| |
| |
| Affected and fixed versions |
| =========================== |
| |
| Fixed in 4.4.302 with commit 5f138ef224dffd15d5e5c5b095859719e0038427 |
| Fixed in 4.9.300 with commit b50f5ca60475710bbc9a3af32fbfc17b1e69c2f0 |
| Fixed in 4.14.265 with commit 546ba238535d925254e0b3f12012a5c55801e2f3 |
| Fixed in 4.19.228 with commit 5904dfd3ddaff3bf4a41c3baf0a8e8f31ed4599b |
| Fixed in 5.4.176 with commit 9c61fce322ac2ef7fecf025285353570d60e41d6 |
| Fixed in 5.10.96 with commit e3b131e30e612ff0e32de6c1cb4f69f89db29193 |
| Fixed in 5.15.19 with commit 9340226388c66a7e090ebb00e91ed64a753b6c26 |
| Fixed in 5.16.5 with commit c9a18f7c5b071dce5e6939568829d40994866ab0 |
| Fixed in 5.17 with commit 26fbe9772b8c459687930511444ce443011f86bf |
| |
| Please see https://www.kernel.org for a full list of currently supported |
| kernel versions by the kernel community. |
| |
| Unaffected versions might change over time as fixes are backported to |
| older supported kernel versions. The official CVE entry at |
| https://cve.org/CVERecord/?id=CVE-2022-48760 |
| will be updated if fixes are backported, please check that for the most |
| up to date information about this issue. |
| |
| |
| Affected files |
| ============== |
| |
| The file(s) affected by this issue are: |
| drivers/usb/core/hcd.c |
| drivers/usb/core/urb.c |
| |
| |
| Mitigation |
| ========== |
| |
| The Linux kernel CVE team recommends that you update to the latest |
| stable kernel version for this, and many other bugfixes. Individual |
| changes are never tested alone, but rather are part of a larger kernel |
| release. Cherry-picking individual commits is not recommended or |
| supported by the Linux kernel community at all. If however, updating to |
| the latest release is impossible, the individual changes to resolve this |
| issue can be found at these commits: |
| https://git.kernel.org/stable/c/5f138ef224dffd15d5e5c5b095859719e0038427 |
| https://git.kernel.org/stable/c/b50f5ca60475710bbc9a3af32fbfc17b1e69c2f0 |
| https://git.kernel.org/stable/c/546ba238535d925254e0b3f12012a5c55801e2f3 |
| https://git.kernel.org/stable/c/5904dfd3ddaff3bf4a41c3baf0a8e8f31ed4599b |
| https://git.kernel.org/stable/c/9c61fce322ac2ef7fecf025285353570d60e41d6 |
| https://git.kernel.org/stable/c/e3b131e30e612ff0e32de6c1cb4f69f89db29193 |
| https://git.kernel.org/stable/c/9340226388c66a7e090ebb00e91ed64a753b6c26 |
| https://git.kernel.org/stable/c/c9a18f7c5b071dce5e6939568829d40994866ab0 |
| https://git.kernel.org/stable/c/26fbe9772b8c459687930511444ce443011f86bf |
