Wind River Support Network

Description

In the Linux kernel, the following vulnerability has been resolved:USB: core: Fix hang in usb_kill_urb by adding memory barriersThe syzbot fuzzer has identified a bug in which processes hang waitingfor usb_kill_urb() to return.  It turns out the issue is not unlinkingthe URB; that works just fine.  Rather, the problem arises when thewakeup 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 ondifferent 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 cansee 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 "StoreBuffering"), and it is well known that without suitable enforcement ofthe desired order of accesses -- in the form of memory barriers -- itis entirely possible for one or both CPUs to execute their reads aheadof their writes.  The end result will be that sometimes CPU 0 sees theold un-decremented value of urb->use_count while CPU 1 sees the oldun-incremented value of urb->reject.  Consequently CPU 0 ends up onthe wait queue and never gets woken up, leading to the observed hangin usb_kill_urb().The same pattern of accesses occurs in usb_poison_urb() and thefailure pathway of usb_hcd_submit_urb().The problem is fixed by adding suitable memory barriers.  To provideproper memory-access ordering in the SB pattern, a full barrier isrequired on both CPUs.  The atomic_inc() and atomic_dec() accessesthemselves don't provide any memory ordering, but since they arepresent, we can use the optimized smp_mb__after_atomic() memorybarrier in the various routines to obtain the desired effect.This patch adds the necessary memory barriers.

CREATE(Triage):(User=admin) CVE-2022-48760 (https://nvd.nist.gov/vuln/detail/CVE-2022-48760)

CVEs

• CVE-2022-48760