CVE-2026-99038 in Linux
Sumário
de VulDB • 24/10/2026
No kernel Linux, a seguinte vulnerabilidade foi resolvida:
memstick: rtsx_usb_ms: concluir solicitações após a ejeção em vez de descartá-las
O memstick_check() pode passar na verificação host->removing logo antes que o rtsx_usb_ms_drv_remove() defina eject/removing. A próxima solicitação é então silenciosamente descartada: o rtsx_usb_ms_request() ignora o schedule_work() assim que eject está definido, e o cancel_work_sync() do drv_remove também pode cancelar um handle_req enfileirado antes de pegar a solicitação. Ninguém completa card->mrq_complete.
Quando o core memstick aguardar por solicitações sem tempo limite ("memstick: core: wait for request completion before freeing card"), isso causará uma trava na remoção: o memstick_check() nunca retorna e o memstick_remove_host() bloqueia-se no flush_workqueue():
INFO: task kworker/u10:3:65 blocked for more than 20 seconds. Workqueue: kmemstick memstick_check __wait_for_common memstick_check
INFO: task kworker/1:1:33 blocked for more than 20 seconds. Workqueue: usb_hub_wq hub_event __flush_workqueue memstick_remove_host rtsx_usb_ms_drv_remove
Nunca descarte uma solicitação. O rtsx_usb_ms_request() sempre agenda o handle_req, e o handle_req falha nas solicitações com -ENOMEDIUM assim que eject está definido, sem tocar no dispositivo. O drv_remove faz flush do handle_req em vez de cancelá-lo, e só o cancela após o memstick_remove_host(), quando nenhuma nova solicitação pode chegar, para que não possa ser executado em um host liberado (freed).
O drain do host_mutex no drv_remove é removido: o handle_req sempre deixa host->req NULL ao terminar, portanto, o drain nunca teve nada a fazer, e agora entraria em condição de corrida (race condition) com o handle_req.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.