CVE-2026-99038 in Linux
Zusammenfassung
von VulDB • 23.10.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
memstick: rtsx_usb_ms: Anforderungen nach dem Entfernen abschließen, anstatt sie zu verwerfen
memstick_check() kann seine Prüfung von host->removing gerade dann bestehen, bevor rtsx_usb_ms_drv_remove() eject/removing setzt. Seine nächste Anforderung wird daraufhin stillschweigend verworfen: rtsx_usb_ms_request() überspringt schedule_work(), sobald eject gesetzt ist, und cancel_work_sync() aus drv_remove kann auch eine wartende handle_req abbrechen, bevor sie die Anforderung aufnimmt. Niemand führt card->mrq_complete durch.
Sobald der memstick-Core auf Anforderungen ohne Timeout wartet („memstick: core: wait for request completion before freeing card“), hängt das Entfernen fest: memstick_check() kehrt niemals zurück und memstick_remove_host() blockiert in flush_workqueue():
INFO: Task kworker/u10:3:65 ist seit mehr als 20 Sekunden gesperrt. Workqueue: kmemstick memstick_check __wait_for_common memstick_check
INFO: Task kworker/1:1:33 ist seit mehr als 20 Sekunden gesperrt. Workqueue: usb_hub_wq hub_event __flush_workqueue memstick_remove_host rtsx_usb_ms_drv_remove
Verwerfen Sie niemals eine Anforderung. rtsx_usb_ms_request() plant handle_req immer, und handle_req schlägt Anforderungen mit -ENOMEDIUM fehl, sobald eject gesetzt ist, ohne das Gerät zu berühren. drv_remove spült (flushes) handle_req anstatt es abzubrechen, und bricht es erst nach memstick_remove_host() ab, wenn keine neue Anforderung mehr eintreffen kann, sodass es nicht auf einem freigegebenen Host ausgeführt werden kann.
Der host_mutex-Abfluss in drv_remove wird entfernt: handle_req hinterlässt immer host->req als NULL, wenn es abgeschlossen ist, daher hatte der Abfluss nie etwas zu tun, und er würde nun mit handle_req um eine Race Condition konkurrieren.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.