CVE-2026-99038

In the Linux kernel, the following vulnerability has been resolved:

memstick: rtsx usb ms: complete requests after eject instead of dropping them

memstick check() can pass its host->removing check just before rtsx usb ms drv remove() sets eject/removing. Its next request is then silently dropped: rtsx usb ms request() skips schedule work() once eject is set, and drv remove's cancel work sync() can also cancel a queued handle req before it picks the request up. Nobody completes card->mrq complete.

Once memstick core waits for requests without a timeout ("memstick: core: wait for request completion before freeing card"), this hangs removal: memstick check() never returns and memstick remove host() blocks in 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

Never drop a request. rtsx usb ms request() always schedules handle req, and handle req fails requests with -ENOMEDIUM once eject is set, without touching the device. drv remove flushes handle req instead of cancelling it, and cancels it only after memstick remove host(), when no new request can arrive, so it cannot run on a freed host.

The host mutex drain in drv remove is removed: handle req always leaves host->req NULL when it finishes, so the drain never had anything to do, and it would now race with handle req.