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")
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: gadget: f_fs: corrige la ejecución entre aio_cancel() y la solicitud AIO. Las aplicaciones basadas en FFS completas pueden utilizar la devolución de llamada aio_cancel() para quitar de la cola las solicitudes USB pendientes enviadas al UDC. Existe un escenario en el que la aplicación FFS emite una llamada de cancelación de AIO, mientras el UDC maneja una desconexión suave. Para una implementación basada en DWC3, la pila de llamadas se parece a la siguiente: Aplicación DWC3 Gadget FFS 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() Actualmente no hay ningún bloqueo implementado entre el controlador de finalización de AIO y la cancelación de AIO, por lo que el problema ocurre si la rutina de finalización se ejecuta en paralelo a una llamada de cancelación de AIO proveniente de la aplicación FFS. A medida que la llamada de finalización libera la solicitud USB (io_data->req), la aplicación FFS también hace referencia a ella para la llamada usb_ep_dequeue(). Esto puede llevar a acceder a un puntero obsoleto/colgado. commit b566d38857fc ("usb: gadget: f_fs: use io_data->status consistentemente") reubicó usb_ep_free_request() en ffs_epfile_async_io_complete(). Sin embargo, para implementar correctamente el bloqueo para mitigar este problema, el spinlock no se puede agregar a ffs_epfile_async_io_complete(), ya que usb_ep_dequeue() (si se elimina con éxito una solicitud USB) llamará al controlador de finalización del controlador de función en el mismo contexto. De ahí que se llegue a un punto muerto. Solucione este problema moviendo usb_ep_free_request() de nuevo a ffs_user_copy_worker() y asegurándose de que establezca explícitamente io_data->req en NULL después de liberarlo dentro de ffs->eps_lock. Esto resuelve la condición de ejecución anterior, ya que la rutina ffs_aio_cancel() no continuará intentando sacar de la cola una solicitud que ya ha sido liberada, o ffs_user_copy_work() no liberará la solicitud USB hasta que la cancelación de AIO termine de hacer referencia a ella. Esta solución depende de el commit b566d38857fc ("usb: gadget: f_fs: use io_data->status consistentemente")
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
| Attack Vector | LOCAL |
|---|---|
| Attack Complexity | LOW |
| Privileges Required | LOW |
| User Interaction | NONE |
| Scope | UNCHANGED |
| Confidentiality Impact | HIGH |
| Integrity Impact | HIGH |
| Availability Impact | HIGH |
Source: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
Type: Secondary
Exploitability Score: 1.8
Impact Score: 5.9
| Source | Type | Description |
|---|---|---|
| 134c704f-9b21-4f2e-91b3-4a467353bcc0 | Secondary |
en
CWE-362
|
| Vendor | Product | Version | Update | Type |
|---|---|---|---|---|
| linux | linux_kernel | * | <built-in method update of dict object at 0x7fd36a6d5900> | Operating System |
| linux | linux_kernel | * | <built-in method update of dict object at 0x7fd36b435b80> | Operating System |
| linux | linux_kernel | * | <built-in method update of dict object at 0x7fd34b8d8140> | Operating System |
| linux | linux_kernel | * | <built-in method update of dict object at 0x7fd340225f40> | Operating System |
| linux | linux_kernel | * | <built-in method update of dict object at 0x7fd36b434900> | Operating System |
| linux | linux_kernel | * | <built-in method update of dict object at 0x7fd36b434b80> | Operating System |
| linux | linux_kernel | * | <built-in method update of dict object at 0x7fd340ad5d40> | Operating System |
| linux | linux_kernel | 6.9 | <built-in method update of dict object at 0x7fd340ad7840> | Operating System |
| linux | linux_kernel | 6.9 | <built-in method update of dict object at 0x7fd340225640> | Operating System |
| linux | linux_kernel | 6.9 | <built-in method update of dict object at 0x7fd36b436780> | Operating System |
| linux | linux_kernel | 6.9 | <built-in method update of dict object at 0x7fd36be7b700> | Operating System |
| linux | linux_kernel | 6.9 | <built-in method update of dict object at 0x7fd36b437640> | Operating System |
| linux | linux_kernel | 6.9 | <built-in method update of dict object at 0x7fd34b8d8440> | Operating System |
| Vulnerable | CPE |
|---|---|
| Yes | cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* |
| Yes | cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* |
| Yes | cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* |
| Yes | cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* |
| Yes | cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* |
| Yes | cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* |
| Yes | cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* |
| Yes | cpe:2.3:o:linux:linux_kernel:6.9:rc1:*:*:*:*:*:* |
| Yes | cpe:2.3:o:linux:linux_kernel:6.9:rc2:*:*:*:*:*:* |
| Yes | cpe:2.3:o:linux:linux_kernel:6.9:rc3:*:*:*:*:*:* |
| Yes | cpe:2.3:o:linux:linux_kernel:6.9:rc4:*:*:*:*:*:* |
| Yes | cpe:2.3:o:linux:linux_kernel:6.9:rc5:*:*:*:*:*:* |
| Yes | cpe:2.3:o:linux:linux_kernel:6.9:rc6:*:*:*:*:*:* |