CVE-2022-49398

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: dwc3: gadget: Replace list_for_each_entry_safe() if using giveback<br /> <br /> The list_for_each_entry_safe() macro saves the current item (n) and<br /> the item after (n+1), so that n can be safely removed without<br /> corrupting the list. However, when traversing the list and removing<br /> items using gadget giveback, the DWC3 lock is briefly released,<br /> allowing other routines to execute. There is a situation where, while<br /> items are being removed from the cancelled_list using<br /> dwc3_gadget_ep_cleanup_cancelled_requests(), the pullup disable<br /> routine is running in parallel (due to UDC unbind). As the cleanup<br /> routine removes n, and the pullup disable removes n+1, once the<br /> cleanup retakes the DWC3 lock, it references a request who was already<br /> removed/handled. With list debug enabled, this leads to a panic.<br /> Ensure all instances of the macro are replaced where gadget giveback<br /> is used.<br /> <br /> Example call stack:<br /> <br /> Thread#1:<br /> __dwc3_gadget_ep_set_halt() - CLEAR HALT<br /> -&gt; dwc3_gadget_ep_cleanup_cancelled_requests()<br /> -&gt;list_for_each_entry_safe()<br /> -&gt;dwc3_gadget_giveback(n)<br /> -&gt;dwc3_gadget_del_and_unmap_request()- n deleted[cancelled_list]<br /> -&gt;spin_unlock<br /> -&gt;Thread#2 executes<br /> ...<br /> -&gt;dwc3_gadget_giveback(n+1)<br /> -&gt;Already removed!<br /> <br /> Thread#2:<br /> dwc3_gadget_pullup()<br /> -&gt;waiting for dwc3 spin_lock<br /> ...<br /> -&gt;Thread#1 released lock<br /> -&gt;dwc3_stop_active_transfers()<br /> -&gt;dwc3_remove_requests()<br /> -&gt;fetches n+1 item from cancelled_list (n removed by Thread#1)<br /> -&gt;dwc3_gadget_giveback()<br /> -&gt;dwc3_gadget_del_and_unmap_request()- n+1 deleted[cancelled_list]<br /> -&gt;spin_unlock