CVE-2022-48760

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> USB: core: Fix hang in usb_kill_urb by adding memory barriers<br /> <br /> The syzbot fuzzer has identified a bug in which processes hang waiting<br /> for usb_kill_urb() to return. It turns out the issue is not unlinking<br /> the URB; that works just fine. Rather, the problem arises when the<br /> wakeup notification that the URB has completed is not received.<br /> <br /> The reason is memory-access ordering on SMP systems. In outline form,<br /> usb_kill_urb() and __usb_hcd_giveback_urb() operating concurrently on<br /> different CPUs perform the following actions:<br /> <br /> CPU 0 CPU 1<br /> ---------------------------- ---------------------------------<br /> usb_kill_urb(): __usb_hcd_giveback_urb():<br /> ... ...<br /> atomic_inc(&amp;urb-&gt;reject); atomic_dec(&amp;urb-&gt;use_count);<br /> ... ...<br /> wait_event(usb_kill_urb_queue,<br /> atomic_read(&amp;urb-&gt;use_count) == 0);<br /> if (atomic_read(&amp;urb-&gt;reject))<br /> wake_up(&amp;usb_kill_urb_queue);<br /> <br /> Confining your attention to urb-&gt;reject and urb-&gt;use_count, you can<br /> see that the overall pattern of accesses on CPU 0 is:<br /> <br /> write urb-&gt;reject, then read urb-&gt;use_count;<br /> <br /> whereas the overall pattern of accesses on CPU 1 is:<br /> <br /> write urb-&gt;use_count, then read urb-&gt;reject.<br /> <br /> This pattern is referred to in memory-model circles as SB (for "Store<br /> Buffering"), and it is well known that without suitable enforcement of<br /> the desired order of accesses -- in the form of memory barriers -- it<br /> is entirely possible for one or both CPUs to execute their reads ahead<br /> of their writes. The end result will be that sometimes CPU 0 sees the<br /> old un-decremented value of urb-&gt;use_count while CPU 1 sees the old<br /> un-incremented value of urb-&gt;reject. Consequently CPU 0 ends up on<br /> the wait queue and never gets woken up, leading to the observed hang<br /> in usb_kill_urb().<br /> <br /> The same pattern of accesses occurs in usb_poison_urb() and the<br /> failure pathway of usb_hcd_submit_urb().<br /> <br /> The problem is fixed by adding suitable memory barriers. To provide<br /> proper memory-access ordering in the SB pattern, a full barrier is<br /> required on both CPUs. The atomic_inc() and atomic_dec() accesses<br /> themselves don&amp;#39;t provide any memory ordering, but since they are<br /> present, we can use the optimized smp_mb__after_atomic() memory<br /> barrier in the various routines to obtain the desired effect.<br /> <br /> This patch adds the necessary memory barriers.