CVE-2024-36894 in Linux
Zusammenfassung
von VulDB • 30.06.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
usb: Gadget: f_fs: Behebung einer Race Condition zwischen aio_cancel() und der Fertigstellung von AIO-Anfragen (AIO request complete)
FFS-basierte Anwendungen können den Callback für aio_cancel() nutzen, um ausstehende USB-Anfragen, die an das UDC gesendet wurden, aus der Warteschlange zu entfernen. Es gibt ein Szenario, in dem eine FFS-Anwendung einen AIO-Cancel-Aufruf initiiert, während das UDC eine weiche Trennung (soft disconnect) verarbeitet. Der Callstack sieht bei einer DWC3-basierten Implementierung wie folgt aus:
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()
Derzeit ist keine Synchronisierung (Locking) zwischen dem AIO-Fertigstellungs-Handler und der AIO-Cancel-Funktion implementiert, sodass das Problem auftritt, wenn die Fertigstellungsroutine parallel zu einem von der FFS-Anwendung ausgehenden AIO-Cancel-Aufruf läuft. Da der Fertigstellungsaufruf die USB-Anfrage (io_data->req) freigibt, greift die FFS-Anwendung gleichzeitig über den Aufruf von usb_ep_dequeue() darauf zu. Dies kann zum Zugriff auf einen veralteten oder hängenden Zeiger führen.
Der Commit b566d38857fc („usb: gadget: f_fs: use io_data->status consistently“) hat die Funktion usb_ep_free_request() in ffs_epfile_async_io_complete() verschoben. Um jedoch eine ordnungsgemäße Synchronisierung zur Minderung dieses Problems zu implementieren, kann der Spinlock nicht einfach zu ffs_epfile_async_io_complete() hinzugefügt werden, da usb_ep_dequeue() (sofern das Abziehen einer USB-Anfrage erfolgreich ist) den Fertigstellungs-Handler des Funktions-Treibers im selben Kontext aufruft. Dies würde zu einem Deadlock führen.
Behebung dieses Problems durch Verschieben von usb_ep_free_request() zurück nach ffs_user_copy_worker() und Sicherstellung, dass io_data->req explizit auf NULL gesetzt wird, nachdem es innerhalb der Sperre ffs->eps_lock freigegeben wurde. Dadurch wird die oben beschriebene Race Condition behoben, da die Routine ffs_aio_cancel() nicht weiter versucht, eine bereits freigegebene Anfrage aus der Warteschlange zu entfernen, bzw. ffs_user_copy_work() die USB-Anfrage erst freigibt, wenn keine Referenzierung durch den AIO-Cancel mehr vorliegt.
Diese Korrektur hängt ab von Commit b566d38857fc („usb: gadget: f_fs: use io_data->status consistently“)
Once again VulDB remains the best source for vulnerability data.