CVE-2024-36894

{"id": "CVE-2024-36894", "metrics": {"cvssMetricV31": [{"type": "Secondary", "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "cvssData": {"scope": "UNCHANGED", "version": "3.1", "baseScore": 5.6, "attackVector": "PHYSICAL", "baseSeverity": "MEDIUM", "vectorString": "CVSS:3.1/AV:P/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:H", "integrityImpact": "NONE", "userInteraction": "NONE", "attackComplexity": "HIGH", "availabilityImpact": "HIGH", "privilegesRequired": "LOW", "confidentialityImpact": "HIGH"}, "impactScore": 5.2, "exploitabilityScore": 0.4}]}, "published": "2024-05-30T16:15:12.857", "references": [{"url": "https://git.kernel.org/stable/c/24729b307eefcd7c476065cd7351c1a018082c19", "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/3613e5023f09b3308545e9d1acda86017ebd418a", "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/73c05ad46bb4fbbdb346004651576d1c8dbcffbb", "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/9e72ef59cbe61cd1243857a6418ca92104275867", "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/a0fdccb1c9e027e3195f947f61aa87d6d0d2ea14", "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/d7461830823242702f5d84084bcccb25159003f4", "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/e500b1c4e29ad0bd1c1332a1eaea2913627a92dd", "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/f71a53148ce34898fef099b75386a3a9f4449311", "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/24729b307eefcd7c476065cd7351c1a018082c19", "source": "af854a3a-2127-422b-91ae-364da2661108"}, {"url": "https://git.kernel.org/stable/c/3613e5023f09b3308545e9d1acda86017ebd418a", "source": "af854a3a-2127-422b-91ae-364da2661108"}, {"url": "https://git.kernel.org/stable/c/73c05ad46bb4fbbdb346004651576d1c8dbcffbb", "source": "af854a3a-2127-422b-91ae-364da2661108"}, {"url": "https://git.kernel.org/stable/c/9e72ef59cbe61cd1243857a6418ca92104275867", "source": "af854a3a-2127-422b-91ae-364da2661108"}, {"url": "https://git.kernel.org/stable/c/a0fdccb1c9e027e3195f947f61aa87d6d0d2ea14", "source": "af854a3a-2127-422b-91ae-364da2661108"}, {"url": "https://git.kernel.org/stable/c/d7461830823242702f5d84084bcccb25159003f4", "source": "af854a3a-2127-422b-91ae-364da2661108"}, {"url": "https://git.kernel.org/stable/c/e500b1c4e29ad0bd1c1332a1eaea2913627a92dd", "source": "af854a3a-2127-422b-91ae-364da2661108"}, {"url": "https://git.kernel.org/stable/c/f71a53148ce34898fef099b75386a3a9f4449311", "source": "af854a3a-2127-422b-91ae-364da2661108"}], "vulnStatus": "Awaiting Analysis", "weaknesses": [{"type": "Secondary", "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "description": [{"lang": "en", "value": "CWE-362"}]}], "descriptions": [{"lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nusb: gadget: f_fs: Fix race between aio_cancel() and AIO request complete\n\nFFS based applications can utilize the aio_cancel() callback to dequeue\npending USB requests submitted to the UDC. There is a scenario where the\nFFS application issues an AIO cancel call, while the UDC is handling a\nsoft disconnect. For a DWC3 based implementation, the callstack looks\nlike the following:\n\n DWC3 Gadget FFS Application\ndwc3_gadget_soft_disconnect() ...\n --> dwc3_stop_active_transfers()\n --> dwc3_gadget_giveback(-ESHUTDOWN)\n --> ffs_epfile_async_io_complete() ffs_aio_cancel()\n --> usb_ep_free_request() --> usb_ep_dequeue()\n\nThere is currently no locking implemented between the AIO completion\nhandler and AIO cancel, so the issue occurs if the completion routine is\nrunning in parallel to an AIO cancel call coming from the FFS application.\nAs the completion call frees the USB request (io_data->req) the FFS\napplication is also referencing it for the usb_ep_dequeue() call. This can\nlead to accessing a stale/hanging pointer.\n\ncommit b566d38857fc (\"usb: gadget: f_fs: use io_data->status consistently\")\nrelocated the usb_ep_free_request() into ffs_epfile_async_io_complete().\nHowever, in order to properly implement locking to mitigate this issue, the\nspinlock can't be added to ffs_epfile_async_io_complete(), as\nusb_ep_dequeue() (if successfully dequeuing a USB request) will call the\nfunction driver's completion handler in the same context. Hence, leading\ninto a deadlock.\n\nFix this issue by moving the usb_ep_free_request() back to\nffs_user_copy_worker(), and ensuring that it explicitly sets io_data->req\nto NULL after freeing it within the ffs->eps_lock. This resolves the race\ncondition above, as the ffs_aio_cancel() routine will not continue\nattempting to dequeue a request that has already been freed, or the\nffs_user_copy_work() not freeing the USB request until the AIO cancel is\ndone referencing it.\n\nThis fix depends on\n commit b566d38857fc (\"usb: gadget: f_fs: use io_data->status\n consistently\")"}, {"lang": "es", "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: gadget: f_fs: corrige la ejecuci\u00f3n entre aio_cancel() y la solicitud AIO. Las aplicaciones basadas en FFS completas pueden utilizar la devoluci\u00f3n de llamada aio_cancel() para quitar de la cola las solicitudes USB pendientes enviadas al UDC. Existe un escenario en el que la aplicaci\u00f3n FFS emite una llamada de cancelaci\u00f3n de AIO, mientras el UDC maneja una desconexi\u00f3n suave. Para una implementaci\u00f3n basada en DWC3, la pila de llamadas se parece a la siguiente: Aplicaci\u00f3n 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\u00fan bloqueo implementado entre el controlador de finalizaci\u00f3n de AIO y la cancelaci\u00f3n de AIO, por lo que el problema ocurre si la rutina de finalizaci\u00f3n se ejecuta en paralelo a una llamada de cancelaci\u00f3n de AIO proveniente de la aplicaci\u00f3n FFS. A medida que la llamada de finalizaci\u00f3n libera la solicitud USB (io_data->req), la aplicaci\u00f3n FFS tambi\u00e9n 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\u00f3 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 \u00e9xito una solicitud USB) llamar\u00e1 al controlador de finalizaci\u00f3n del controlador de funci\u00f3n en el mismo contexto. De ah\u00ed que se llegue a un punto muerto. Solucione este problema moviendo usb_ep_free_request() de nuevo a ffs_user_copy_worker() y asegur\u00e1ndose de que establezca expl\u00edcitamente io_data->req en NULL despu\u00e9s de liberarlo dentro de ffs->eps_lock. Esto resuelve la condici\u00f3n de ejecuci\u00f3n anterior, ya que la rutina ffs_aio_cancel() no continuar\u00e1 intentando sacar de la cola una solicitud que ya ha sido liberada, o ffs_user_copy_work() no liberar\u00e1 la solicitud USB hasta que la cancelaci\u00f3n de AIO termine de hacer referencia a ella. Esta soluci\u00f3n depende de el commit b566d38857fc (\"usb: gadget: f_fs: use io_data->status consistentemente\")"}], "lastModified": "2024-11-21T09:22:45.220", "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}