Cloudanix VulnDB

CVE-2026-99039

None

CVSS

—

EPSS

0.2%

Published

Oct 23, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A timing problem in the Linux kernel's handling of certain memory cards can let the system write to memory it has already released, which may crash the machine or allow an attacker with physical access to run code.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Privilege Gain
Component
OS kernel
Class
Use After Free
Remediation
Patch
Effort
Low
Patch risk
Low

What it actually does

Use-after-free write in memstick core: wait_for_completion_timeout() allows memstick_dev to be kfree'd while host controller driver (rtsx_usb_ms, jmb38x_ms, etc.) still holds a pointer to it and later performs a write via ms_read_bytes in worker context.

Why it matters to the business

Systems using memory-stick or compatible removable media can experience kernel crashes, memory corruption, or potential local privilege escalation when device responses are delayed, affecting stability and security of servers, workstations, and embedded devices that rely on the memstick subsystem.

How an attack unfolds

An attacker with local access or control over a memstick-compatible device inserts or configures media that causes the identification or address-setup request to time out; the allocation path frees the card structure while the asynchronous host driver request remains in flight; when the worker thread later completes the transfer it writes into the freed memory, triggering slab-use-after-free.

How to fix it

Replace wait_for_completion_timeout() with wait_for_completion() in memstick_alloc_card() and memstick_set_rw_addr() as described in the upstream fix; apply the corresponding Linux kernel patch or newer mainline/stable release that contains the change.

How to confirm the fix worked

Rebuild or boot a kernel containing the fix and confirm absence of the KASAN slab-use-after-free report in ms_read_bytes when exercising memstick device insertion under delayed-response conditions; verify source contains unconditional wait_for_completion calls in the two affected functions.

Typical attack path

  1. Insert or configure a memstick device that delays response to identification or rw-addr commands
  2. Trigger memstick_check or memstick_alloc_card path that uses timed wait
  3. Allow wait_for_completion_timeout to expire and free the memstick_dev
  4. Wait for host driver worker (e.g. rtsx_usb_ms_handle_req) to finish transfer and write to dangling pointer

How to detect it

Search kernel logs and KASAN reports for slab-use-after-free involving ms_read_bytes, memstick_alloc_card, or rtsx_usb_ms_handle_req; inspect workqueue traces showing events worker completing after card kfree.

  • BUG: KASAN: slab-use-after-free in ms_read_bytes
  • rtsx_usb_ms_handle_req
  • memstick_alloc_card drivers/memstick/core/memstick.c
  • Workqueue: events rtsx_usb_ms_handle_req

What your security team should do

  • Prioritize kernel updates for all systems exposing memstick or compatible host controllers
  • Monitor for KASAN or slab corruption reports referencing memstick and rtsx_usb_ms / jmb38x_ms drivers
  • Consider disabling memstick support via kernel config if the hardware is not required

The record

In the Linux kernel, the following vulnerability has been resolved: memstick: core: wait for request completion before freeing card In memstick_alloc_card() and memstick_set_rw_addr(), wait_for_completion_timeout() is used to wait for device identification and address configuration requests to complete. The memstick subsystem does not provide an abort or cancellation callback in struct memstick_host for in-flight requests. If wait_for_completion_timeout() expires (for instance, when a USB transfer or command retry is delayed), memstick_alloc_card() returns an error and frees the memstick_dev structure via kfree(card). However, the host controller driver (such as rtsx_usb_ms) is still running the request asynchronously in worker context. When the transfer eventually finishes, the driver writes into host->req->data, which points to memory inside the already freed card structure. This leads to a KASAN slab-use-after-free write: BUG: KASAN: slab-use-after-free in ms_read_bytes+0x8fe/0x990 Write of size 1 at addr ffff88813c188079 by task kworker/1:5/5239 Workqueue: events rtsx_usb_ms_handle_req Call Trace: ms_read_bytes+0x8fe/0x990 drivers/memstick/host/rtsx_usb_ms.c:450 rtsx_usb_ms_issue_cmd drivers/memstick/host/rtsx_usb_ms.c:477 [inline] rtsx_usb_ms_handle_req+0x557/0x1a00 drivers/memstick/host/rtsx_usb_ms.c:531 process_one_work+0xac7/0x1b10 kernel/workqueue.c:3396 worker_thread+0x5ef/0xe50 kernel/workqueue.c:3560 kthread+0x373/0x450 kernel/kthread.c:436 Allocated by task 1662: memstick_alloc_card drivers/memstick/core/memstick.c:383 [inline] memstick_check+0x2c1/0x10d0 drivers/memstick/core/memstick.c:452 process_one_work+0xac7/0x1b10 kernel/workqueue.c:3396 Freed by task 1662: kfree+0x20c/0x650 mm/slub.c:6792 memstick_alloc_card drivers/memstick/core/memstick.c:420 [inline] memstick_check+0x72b/0x10d0 drivers/memstick/core/memstick.c:452 process_one_work+0xac7/0x1b10 kernel/workqueue.c:3396 Host controller drivers (rtsx_usb_ms, jmb38x_ms, tifm_ms, r592) already implement their own hardware and bus timeouts, and callers in mspro_block and ms_block already rely on wait_for_completion() unconditionally. Replace wait_for_completion_timeout() with wait_for_completion() in memstick_set_rw_addr() and memstick_alloc_card() so that the card structure is never freed while an asynchronous request is in flight.

Affected packages

Ecosystem Package Introduced Fixed