CVE-2026-99038: Linux Vulnerability

Description

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.

Metrics

EPSS Probability

0.17%

6.1th percentile

Probability of exploitation in the next 30 days. Learn more

Affected Software

Source: CNA advisory (CVE.org). NVD analysis pending.

Vendor	Product	Versions
Linux	Linux	>= 99451dceeb5fdd789f0a2eeb3ee029e80d2ccc40, < c48245ef696e590e92cbfb622625642bec8dbbad; >= 99451dceeb5fdd789f0a2eeb3ee029e80d2ccc40, < 602a00d75d2ab079c9ab7c0d7b56ae436e604148; >= 99451dceeb5fdd789f0a2eeb3ee029e80d2ccc40, < 8e4eda6e1b00624820fea1d35508d7422330ee25; >= 99451dceeb5fdd789f0a2eeb3ee029e80d2ccc40, < f2c181e1d58e911804e14543b2f1cc6b23a0d4d6; >= 99451dceeb5fdd789f0a2eeb3ee029e80d2ccc40, < 5b599e28aeb3684772aef64f46cc6f25f4c67128; >= 99451dceeb5fdd789f0a2eeb3ee029e80d2ccc40, < d7e811c3a49cd5cff529c157df886719e09370ec; >= 99451dceeb5fdd789f0a2eeb3ee029e80d2ccc40, < 5616da0f92339328fa1472876df51555e15ad340; >= 99451dceeb5fdd789f0a2eeb3ee029e80d2ccc40, < c96ca94425b076dc398d929366e378d1e22ec794
Linux	Linux	3.16

References

Timeline

Published: Oct 23, 2026
Last Modified: Oct 30, 2026
Status: Received

Frequently Asked Questions

What is 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.

How severe is CVE-2026-99038?

Severity scoring for CVE-2026-99038 is pending analysis. The EPSS model estimates a 0.17% probability of exploitation in the next 30 days.

How do I fix CVE-2026-99038?

Check the vendor references and advisories linked above for patched versions and mitigation guidance. You can also run a Strix scan to test if your systems are affected.

How Strix Helps

Related CVEs from 2026

View all 2026CVEs →