CVE-2026-99038: memstick: rtsx_usb_ms: complete requests after eject instead of dropping them

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

memstick: rtsxusbms: complete requests after eject instead of dropping them

memstickcheck() can pass its host->removing check just before rtsxusbmsdrvremove() sets eject/removing. Its next request is then silently dropped: rtsxusbmsrequest() skips schedulework() once eject is set, and drvremove's cancelworksync() can also cancel a queued handlereq before it picks the request up. Nobody completes card->mrqcomplete.

Once memstick core waits for requests without a timeout ("memstick: core: wait for request completion before freeing card"), this hangs removal: memstickcheck() never returns and memstickremovehost() blocks in flushworkqueue():

INFO: task kworker/u10:3:65 blocked for more than 20 seconds. Workqueue: kmemstick memstickcheck waitforcommon memstickcheck

INFO: task kworker/1:1:33 blocked for more than 20 seconds. Workqueue: usbhubwq hubevent flushworkqueue memstickremovehost rtsxusbmsdrvremove

Never drop a request. rtsxusbmsrequest() always schedules handlereq, and handlereq fails requests with -ENOMEDIUM once eject is set, without touching the device. drvremove flushes handlereq instead of cancelling it, and cancels it only after memstickremovehost(), when no new request can arrive, so it cannot run on a freed host.

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