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.
OS | Version | Architecture | Package | Version | Filename |
---|---|---|---|---|---|
ubuntu | 18.04 | noarch | linux | < any | UNKNOWN |
ubuntu | 20.04 | noarch | linux | < any | UNKNOWN |
ubuntu | 18.04 | noarch | linux-aws | < any | UNKNOWN |
ubuntu | 20.04 | noarch | linux-aws | < any | UNKNOWN |
ubuntu | 18.04 | noarch | linux-aws-5.4 | < any | UNKNOWN |
ubuntu | 16.04 | noarch | linux-aws-hwe | < any | UNKNOWN |
ubuntu | 20.04 | noarch | linux-azure | < any | UNKNOWN |
ubuntu | 14.04 | noarch | linux-azure | < any | UNKNOWN |
ubuntu | 16.04 | noarch | linux-azure | < any | UNKNOWN |
ubuntu | 18.04 | noarch | linux-azure-4.15 | < any | UNKNOWN |
git.kernel.org/linus/26fbe9772b8c459687930511444ce443011f86bf (5.17-rc2)
git.kernel.org/stable/c/26fbe9772b8c459687930511444ce443011f86bf
git.kernel.org/stable/c/546ba238535d925254e0b3f12012a5c55801e2f3
git.kernel.org/stable/c/5904dfd3ddaff3bf4a41c3baf0a8e8f31ed4599b
git.kernel.org/stable/c/5f138ef224dffd15d5e5c5b095859719e0038427
git.kernel.org/stable/c/9340226388c66a7e090ebb00e91ed64a753b6c26
git.kernel.org/stable/c/9c61fce322ac2ef7fecf025285353570d60e41d6
git.kernel.org/stable/c/b50f5ca60475710bbc9a3af32fbfc17b1e69c2f0
git.kernel.org/stable/c/c9a18f7c5b071dce5e6939568829d40994866ab0
git.kernel.org/stable/c/e3b131e30e612ff0e32de6c1cb4f69f89db29193
launchpad.net/bugs/cve/CVE-2022-48760
nvd.nist.gov/vuln/detail/CVE-2022-48760
security-tracker.debian.org/tracker/CVE-2022-48760
www.cve.org/CVERecord?id=CVE-2022-48760