CVE-2024-36894: usb: gadget: f_fs: Fix race between aio_cancel() and AIO request complete
In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: ffs: Fix race between aiocancel() and AIO request complete
FFS based applications can utilize the aiocancel() callback to dequeue pending USB requests submitted to the UDC. There is a scenario where the FFS application issues an AIO cancel call, while the UDC is handling a soft disconnect. For a DWC3 based implementation, the callstack looks like the following:
DWC3 Gadget FFS Application dwc3gadgetsoftdisconnect() ... --> dwc3stopactivetransfers() --> dwc3gadgetgiveback(-ESHUTDOWN) --> ffsepfileasynciocomplete() ffsaiocancel() --> usbepfreerequest() --> usbepdequeue()
There is currently no locking implemented between the AIO completion handler and AIO cancel, so the issue occurs if the completion routine is running in parallel to an AIO cancel call coming from the FFS application. As the completion call frees the USB request (iodata->req) the FFS application is also referencing it for the usbepdequeue() call. This can lead to accessing a stale/hanging pointer.
commit b566d38857fc ("usb: gadget: ffs: use iodata->status consistently") relocated the usbepfreerequest() into ffsepfileasynciocomplete(). However, in order to properly implement locking to mitigate this issue, the spinlock can't be added to ffsepfileasynciocomplete(), as usbepdequeue() (if successfully dequeuing a USB request) will call the function driver's completion handler in the same context. Hence, leading into a deadlock.
Fix this issue by moving the usbepfreerequest() back to ffsusercopyworker(), and ensuring that it explicitly sets iodata->req to NULL after freeing it within the ffs->epslock. This resolves the race condition above, as the ffsaiocancel() routine will not continue attempting to dequeue a request that has already been freed, or the ffsusercopywork() not freeing the USB request until the AIO cancel is done referencing it.
This fix depends on commit b566d38857fc ("usb: gadget: ffs: use iodata->status consistently")
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 5.10.223-1Fixed in 5.10.234-1Fixed in 6.1.129-1Fixed in 6.1.135-1Fixed in 6.12.22-1Fixed in 6.12.25-1 - Upgrade
Upgrade
debian/linux-6.1to a version that resolves this vulnerability.Fixed in 6.1.129-1~deb11u1 - Upgrade
Upgrade
Linux kernel usb: gadget: f_fsto a version that resolves this vulnerability.Patch b566d38857fc - Upgrade
Upgrade
Linux kernel usb: gadget: f_fsto a version that resolves this vulnerability.Patch b566d38857fc (
Event History
Frequently Asked Questions
What is the severity of CVE-2024-36894?
CVE-2024-36894 has a moderate severity rating due to potential race conditions in USB request handling.
How do I fix CVE-2024-36894?
To fix CVE-2024-36894, update your Linux kernel to versions 5.10.223-1, 5.10.226-1, 6.1.119-1, or later.
Which systems are affected by CVE-2024-36894?
Systems running specific versions of the Linux kernel, such as 5.10.x and 6.1.x, are affected by CVE-2024-36894.
What is the impact of CVE-2024-36894?
The impact of CVE-2024-36894 includes potential denial of service through mishandled asynchronous IO requests.
Is CVE-2024-36894 related to USB functionality?
Yes, CVE-2024-36894 specifically addresses a vulnerability in USB gadget functionality within the Linux kernel.