Cloudanix VulnDB

CVE-2026-99038

None

CVSS

—

EPSS

0.2%

Published

Oct 23, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A timing bug when unplugging certain USB memory cards can freeze parts of the operating system and make the computer unresponsive.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Race Condition
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Race condition in the rtsx_usb_ms memstick driver allows requests to be silently dropped on eject instead of completed, causing memstick_check to hang indefinitely waiting for request completion without timeout and blocking memstick_remove_host during device removal.

Why it matters to the business

Removal of certain USB memory stick devices can trigger prolonged system hangs, blocked kernel workers, and unresponsiveness, disrupting maintenance, hotplug operations, and overall system stability in environments using the affected hardware.

How an attack unfolds

An attacker with local or physical access triggers a precisely timed eject or removal of a compatible USB memstick device to win the race between memstick_check and rtsx_usb_ms_drv_remove, leaving an incomplete request that blocks the removal workqueue and hangs the system.

How to fix it

Update the Linux kernel to a version containing the upstream fix that ensures rtsx_usb_ms_request always schedules handle_req, handle_req fails requests with -ENOMEDIUM on eject, drv_remove flushes instead of cancels work after memstick_remove_host, and removes the host_mutex drain.

How to confirm the fix worked

Confirm the kernel source contains the described changes to rtsx_usb_ms_request, handle_req, and rtsx_usb_ms_drv_remove; test hotplug removal of memstick devices under load to verify no hangs in memstick_check or flush_workqueue.

Typical attack path

  1. Obtain local or physical access to a system with rtsx_usb_ms hardware
  2. Insert a compatible memstick device
  3. Trigger device removal or eject at the exact window after memstick_check passes its host-removing check but before eject flags are set
  4. Observe kernel worker and workqueue blockage leading to system hang

How to detect it

Search kernel logs and workqueue traces for prolonged blocks in memstick_check, flush_workqueue during memstick_remove_host, or rtsx_usb_ms_drv_remove; look for repeated "blocked for more than 20 seconds" messages involving kmemstick or usb_hub_wq.

What your security team should do

  • Prioritize kernel updates on systems exposing memstick or rtsx_usb hardware within the next maintenance window
  • Monitor upstream stable kernel releases for backports of this fix
  • Restrict physical access to USB ports on affected systems until patched
  • Review logs for memstick-related workqueue stalls as a temporary detection measure

The record

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.

Affected packages

Ecosystem Package Introduced Fixed