Cloudanix VulnDB

CVE-2026-98227

None

CVSS

—

EPSS

0.2%

Published

Oct 6, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A flaw in how the system handles certain memory cards causes memory to be lost each time a card is inserted and removed, eventually making the computer unstable after many cycles.

Exploitation
Physical Access
Attacker needs
Physical Access
Complexity
Low
Impact
Denial Of Service
Component
OS kernel
Class
Other
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

Repeated insert/remove cycles on memstick cards leak ordered workqueues and their kworkers because msb_remove() never calls destroy_workqueue() after the init error path.

Why it matters to the business

Systems performing frequent memstick card operations will gradually exhaust kernel memory, eventually causing instability, degraded performance, or crashes that disrupt operations.

How an attack unfolds

An attacker with physical or local access repeatedly inserts and removes memstick cards; each cycle allocates a new workqueue that is never freed, accumulating until kernel memory is exhausted.

How to fix it

Apply the kernel patch that adds destroy_workqueue() in msb_remove() after the disk is removed and the queue is drained; rebuild and deploy the fixed kernel image.

How to confirm the fix worked

Confirm the destroy_workqueue() call exists in msb_remove() in the source, boot the updated kernel, and exercise repeated card insert/remove cycles while monitoring workqueue and memory counters for leaks.

Typical attack path

  1. Obtain local or physical access to a system with memstick hardware
  2. Insert a memstick card to trigger msb_init_disk()
  3. Remove the card to trigger msb_remove() without destroying the workqueue
  4. Repeat the cycle to accumulate leaked kworkers and memory
  5. Continue until kernel memory pressure leads to denial of service

How to detect it

Review kernel logs and slabinfo or workqueue statistics for unexpected growth in ms_block related objects after card removal events; correlate with dmesg entries around memstick device registration.

What your security team should do

  • Prioritize patching kernel packages containing the memstick ms_block driver on all affected systems
  • Monitor kernel memory and workqueue statistics on systems with memstick hardware
  • Restrict physical access to systems exposing memstick slots until patched

The record

In the Linux kernel, the following vulnerability has been resolved: memstick: ms_block: destroy io_queue workqueue on removal msb_init_disk() creates the per-card ordered workqueue msb->io_queue with alloc_ordered_workqueue(). It is torn down with destroy_workqueue() only on the init error path; msb_remove() never destroys it. msb_stop() merely flushes the queue, and neither msb_data_clear() nor put_disk() free it. As a result every card insert/remove cycle leaks the workqueue and its kworker, exhausting kernel memory over repeated cycles. Destroy the workqueue in msb_remove() after the disk has been removed and the queue drained.

Affected packages

Ecosystem Package Introduced Fixed