CVE-2024-36894

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: gadget: f_fs: Fix race between aio_cancel() and AIO request complete<br /> <br /> FFS based applications can utilize the aio_cancel() callback to dequeue<br /> pending USB requests submitted to the UDC. There is a scenario where the<br /> FFS application issues an AIO cancel call, while the UDC is handling a<br /> soft disconnect. For a DWC3 based implementation, the callstack looks<br /> like the following:<br /> <br /> DWC3 Gadget FFS Application<br /> dwc3_gadget_soft_disconnect() ...<br /> --&gt; dwc3_stop_active_transfers()<br /> --&gt; dwc3_gadget_giveback(-ESHUTDOWN)<br /> --&gt; ffs_epfile_async_io_complete() ffs_aio_cancel()<br /> --&gt; usb_ep_free_request() --&gt; usb_ep_dequeue()<br /> <br /> There is currently no locking implemented between the AIO completion<br /> handler and AIO cancel, so the issue occurs if the completion routine is<br /> running in parallel to an AIO cancel call coming from the FFS application.<br /> As the completion call frees the USB request (io_data-&gt;req) the FFS<br /> application is also referencing it for the usb_ep_dequeue() call. This can<br /> lead to accessing a stale/hanging pointer.<br /> <br /> commit b566d38857fc ("usb: gadget: f_fs: use io_data-&gt;status consistently")<br /> relocated the usb_ep_free_request() into ffs_epfile_async_io_complete().<br /> However, in order to properly implement locking to mitigate this issue, the<br /> spinlock can&amp;#39;t be added to ffs_epfile_async_io_complete(), as<br /> usb_ep_dequeue() (if successfully dequeuing a USB request) will call the<br /> function driver&amp;#39;s completion handler in the same context. Hence, leading<br /> into a deadlock.<br /> <br /> Fix this issue by moving the usb_ep_free_request() back to<br /> ffs_user_copy_worker(), and ensuring that it explicitly sets io_data-&gt;req<br /> to NULL after freeing it within the ffs-&gt;eps_lock. This resolves the race<br /> condition above, as the ffs_aio_cancel() routine will not continue<br /> attempting to dequeue a request that has already been freed, or the<br /> ffs_user_copy_work() not freeing the USB request until the AIO cancel is<br /> done referencing it.<br /> <br /> This fix depends on<br /> commit b566d38857fc ("usb: gadget: f_fs: use io_data-&gt;status<br /> consistently")