Cloudanix VulnDB

CVE-2026-90400

None

CVSS

—

EPSS

0.2%

Published

Sep 17, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A timing problem when the system swaps spare drives in a storage array can make the computer crash without warning.

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 Linux md RAID driver allows md_choose_sync_action to act on stale spare configuration after remove_spares or raid10_remove_disk, resulting in rdev_dec_pending called with NULL and subsequent NULL pointer dereference during normal I/O.

Why it matters to the business

Unpatched Linux systems using software RAID can experience sudden kernel crashes and reboots when spare disk operations coincide with array I/O, producing unplanned downtime on storage servers and appliances.

How an attack unfolds

An attacker with local access triggers concurrent RAID spare removal and write requests; the window between the initial stale check and mutex acquisition lets the driver dereference a NULL rdev, crashing the kernel without needing network access or elevated privileges beyond local execution.

How to fix it

Upgrade to a kernel containing the fix that suspends the array before re-checking spare state after acquiring reconfig_mutex; apply the patch or the next stable release that includes the md race-condition correction.

How to confirm the fix worked

Confirm the array suspend-before-recheck logic is present in the running kernel source or verify the md module no longer permits the described stale rdev state transition under concurrent spare and I/O workloads.

Typical attack path

  1. Gain local shell on target Linux system with md/RAID arrays
  2. Issue parallel disk replacement or fault-injection operations while sustained I/O runs against the array
  3. Force the race between md_start_sync check and remove_spares under reconfig_mutex
  4. Trigger NULL dereference in rdev_dec_pending and cause kernel panic

How to detect it

Inspect kernel logs for NULL pointer dereference oops mentioning md, raid10_remove_disk, rdev_dec_pending, or reconfig_mutex contention around the time of array spare changes; correlate with audit logs showing concurrent disk replacement commands.

  • BUG: unable to handle kernel NULL pointer dereference
  • RIP: 0010:rdev_dec_pending
  • md: remove_spares
  • raid10_remove_disk

What your security team should do

  • Prioritize kernel updates on all systems exposing md RAID devices
  • Monitor vendor advisories for the exact upstream commit that enforces array suspension
  • Temporarily restrict unprivileged local access on high-value RAID hosts until patched

The record

In the Linux kernel, the following vulnerability has been resolved: md: recheck spare changes before starting sync remove_spares() and remove_and_add_spares() modify the array's rdev configuration. These operations are only safe after the array has been suspended. md_start_sync() checks whether spare configuration changes are needed before taking reconfig_mutex. However, the rdev state can change before the mutex is acquired, so the initial check can become stale. In that case, md_choose_sync_action() may remove or replace rdevs while normal I/O is still accessing them. The race can occur as follows: raid10d Worker Normal IO ____________ _______________________ ______________________ raid10_write_request() wait_blocked_dev() set Blocked set Faulty Skip Faulty rdev rrdev->nr_pending++ .repl_bio = bio removeable_rdev = false . array not suspended . lock mddev goto err_handle lock mddev (wait) . update sb . clear Blocked . . unlock mddev . lock mddev (acquires) remove_spares() removeable_rdev = true raid10_remove_disk() rdev = replacement replacement = NULL rdev_dec_pending(NULL) unlock mddev (NULL)->nr_pending-- In this case, rdev_dec_pending() is called with a NULL pointer, resulting in a NULL pointer dereference when attempting to decrement nr_pending. Fix this by suspending the array when spare configuration changes are needed, including for non-read-write arrays, and checking again after taking reconfig_mutex. If the array was not already suspended and a change is now needed, release the mutex, suspend the array, and reacquire the mutex before continuing.

Affected packages

Ecosystem Package Introduced Fixed