CVE-2024-36894
"Linux Kernel USB Gadget FFS AIO Dequeue Race"
Description
In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_fs: Fix race between aio_cancel() and AIO request complete FFS based applications can utilize the aio_cancel() 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 dwc3_gadget_soft_disconnect() ... --> dwc3_stop_active_transfers() --> dwc3_gadget_giveback(-ESHUTDOWN) --> ffs_epfile_async_io_complete() ffs_aio_cancel() --> usb_ep_free_request() --> usb_ep_dequeue() 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 (io_data->req) the FFS application is also referencing it for the usb_ep_dequeue() call. This can lead to accessing a stale/hanging pointer. commit b566d38857fc ("usb: gadget: f_fs: use io_data->status consistently") relocated the usb_ep_free_request() into ffs_epfile_async_io_complete(). However, in order to properly implement locking to mitigate this issue, the spinlock can't be added to ffs_epfile_async_io_complete(), as usb_ep_dequeue() (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 usb_ep_free_request() back to ffs_user_copy_worker(), and ensuring that it explicitly sets io_data->req to NULL after freeing it within the ffs->eps_lock. This resolves the race condition above, as the ffs_aio_cancel() routine will not continue attempting to dequeue a request that has already been freed, or the ffs_user_copy_work() not freeing the USB request until the AIO cancel is done referencing it. This fix depends on commit b566d38857fc ("usb: gadget: f_fs: use io_data->status consistently")
INFO
Published Date :
May 30, 2024, 4:15 p.m.
Last Modified :
July 5, 2024, 8:15 a.m.
Source :
416baaa9-dc9f-4396-8d5f-8c081fb06d67
Remotely Exploitable :
No
Impact Score :
5.2
Exploitability Score :
0.4
References to Advisories, Solutions, and Tools
Here, you will find a curated list of external links that provide in-depth
information, practical solutions, and valuable tools related to
CVE-2024-36894
.
We scan GitHub repositories to detect new proof-of-concept exploits. Following list is a collection of public exploits and proof-of-concepts, which have been published on GitHub (sorted by the most recently updated).
Results are limited to the first 15 repositories due to potential performance issues.
The following list is the news that have been mention
CVE-2024-36894
vulnerability anywhere in the article.
The following table lists the changes that have been made to the
CVE-2024-36894
vulnerability over time.
Vulnerability history details can be useful for understanding the evolution of a vulnerability, and for identifying the most recent changes that may impact the vulnerability's severity, exploitability, or other characteristics.
-
CVE Modified by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
Jul. 05, 2024
Action Type Old Value New Value Added Reference kernel.org https://git.kernel.org/stable/c/f71a53148ce34898fef099b75386a3a9f4449311 [No types assigned] Added Reference kernel.org https://git.kernel.org/stable/c/9e72ef59cbe61cd1243857a6418ca92104275867 [No types assigned] Added Reference kernel.org https://git.kernel.org/stable/c/e500b1c4e29ad0bd1c1332a1eaea2913627a92dd [No types assigned] Added Reference kernel.org https://git.kernel.org/stable/c/3613e5023f09b3308545e9d1acda86017ebd418a [No types assigned] -
CVE Modified by 134c704f-9b21-4f2e-91b3-4a467353bcc0
Jul. 03, 2024
Action Type Old Value New Value Added CWE CISA-ADP CWE-362 Added CVSS V3.1 CISA-ADP AV:P/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:H -
CVE Modified by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
Jun. 21, 2024
Action Type Old Value New Value Added Reference kernel.org https://git.kernel.org/stable/c/a0fdccb1c9e027e3195f947f61aa87d6d0d2ea14 [No types assigned] -
CVE Received by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
May. 30, 2024
Action Type Old Value New Value Added Description In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_fs: Fix race between aio_cancel() and AIO request complete FFS based applications can utilize the aio_cancel() 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 dwc3_gadget_soft_disconnect() ... --> dwc3_stop_active_transfers() --> dwc3_gadget_giveback(-ESHUTDOWN) --> ffs_epfile_async_io_complete() ffs_aio_cancel() --> usb_ep_free_request() --> usb_ep_dequeue() 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 (io_data->req) the FFS application is also referencing it for the usb_ep_dequeue() call. This can lead to accessing a stale/hanging pointer. commit b566d38857fc ("usb: gadget: f_fs: use io_data->status consistently") relocated the usb_ep_free_request() into ffs_epfile_async_io_complete(). However, in order to properly implement locking to mitigate this issue, the spinlock can't be added to ffs_epfile_async_io_complete(), as usb_ep_dequeue() (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 usb_ep_free_request() back to ffs_user_copy_worker(), and ensuring that it explicitly sets io_data->req to NULL after freeing it within the ffs->eps_lock. This resolves the race condition above, as the ffs_aio_cancel() routine will not continue attempting to dequeue a request that has already been freed, or the ffs_user_copy_work() not freeing the USB request until the AIO cancel is done referencing it. This fix depends on commit b566d38857fc ("usb: gadget: f_fs: use io_data->status consistently") Added Reference kernel.org https://git.kernel.org/stable/c/73c05ad46bb4fbbdb346004651576d1c8dbcffbb [No types assigned] Added Reference kernel.org https://git.kernel.org/stable/c/d7461830823242702f5d84084bcccb25159003f4 [No types assigned] Added Reference kernel.org https://git.kernel.org/stable/c/24729b307eefcd7c476065cd7351c1a018082c19 [No types assigned]
CWE - Common Weakness Enumeration
While CVE identifies
specific instances of vulnerabilities, CWE categorizes the common flaws or
weaknesses that can lead to vulnerabilities. CVE-2024-36894
is
associated with the following CWEs:
Common Attack Pattern Enumeration and Classification (CAPEC)
Common Attack Pattern Enumeration and Classification
(CAPEC)
stores attack patterns, which are descriptions of the common attributes and
approaches employed by adversaries to exploit the CVE-2024-36894
weaknesses.