---
id: "CVE-2026-99038"
kind: "vulnerability"
aliases: ["CVE-2026-99038"]
title: "Linux kernel: memstick driver can hang removal on rtsx_usb cards"
severity: "unknown"
cvss: null
epss: 0.00209
exploited: false
status: "open"
category: "vendor"
products: []
ecosystems: []
tags: ["kernel", "linux", "memstick", "usb-card-reader", "vendor"]
not_affected_if: ["default-config"]
published_at: "2026-10-23T13:17:27+00:00"
first_seen_at: "2026-10-23T21:57:33+00:00"
updated_at: "2026-10-25T12:38:50+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-99038", "first_seen_at": "2026-10-23T21:57:33+00:00"}, {"source": "epss", "url": "https://api.first.org/data/v1/epss?cve=CVE-2026-99038", "first_seen_at": "2026-10-25T12:38:50+00:00"}]
---

# Linux kernel: memstick driver can hang removal on rtsx_usb cards

A race in the Linux kernel's rtsx_usb_ms memstick driver can drop a request during card removal, so the request never completes. The memstick core then waits forever, hanging the removal path and blocking the workqueue.

_Summary, check and fix written by a model from the sources; labelled as such._

## How to check

- unknown

## Fix

- unknown

## Timeline

- 2026-10-23T21:57:33+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-99038
- 2026-10-25T12:38:50+00:00 epss https://api.first.org/data/v1/epss?cve=CVE-2026-99038

## From the sources

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.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_