Cloudanix VulnDB

CVE-2026-90275

None

CVSS

—

EPSS

0.2%

Published

Sep 17, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A Linux storage feature can get stuck during certain disk-array changes, freezing all disk access until the machine is restarted.

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

What it actually does

raid1_takeover() unconditionally sets array_frozen=1 on a newly kzalloc'd r1conf; after the removal of the subsequent mddev_resume() path that called raid1_quiesce(0), _wait_barrier() permanently observes the flag and stalls all I/O to the array.

Why it matters to the business

Systems performing RAID1 level changes or array takeovers experience immediate, unrecoverable I/O hangs that can only be resolved by reboot or module reload, leading to extended storage outages and potential data inconsistency during recovery.

How an attack unfolds

An attacker with local privileges triggers a RAID level change or takeover operation that invokes raid1_takeover(), leaving array_frozen set; subsequent I/O requests block indefinitely in the barrier wait path, producing a persistent denial of service against the storage array.

How to fix it

Upgrade to a kernel containing the fix that removes the array_frozen assignment inside raid1_takeover(); rebuild and reboot onto the patched kernel. No configuration workaround exists.

How to confirm the fix worked

Confirm the source change that deletes the array_frozen=1 line in raid1_takeover(); after boot, perform a level change on a test RAID1 array and verify that I/O continues without stall.

Typical attack path

  1. Obtain local execution on a system using md RAID1 arrays
  2. Issue mdadm level change or takeover command that reaches raid1_takeover()
  3. Observe array_frozen=1 persisting after the operation
  4. Issue any read/write to the affected array and block in _wait_barrier()

How to detect it

Review kernel logs for repeated barrier-wait messages or hung-task reports on md devices immediately following mdadm level changes or takeover operations; correlate with dmesg entries showing array_frozen state.

What your security team should do

  • Prioritize kernel updates on all systems exposing md RAID1 arrays to untrusted local users
  • Audit mdadm usage in automation and scripts for level-change operations
  • Monitor for stalled I/O on RAID devices after any array reconfiguration

The record

In the Linux kernel, the following vulnerability has been resolved: md/raid1: don't set array_frozen in raid1_takeover() raid1_takeover() sets conf->array_frozen = 1 on the newly-allocated r1conf and nothing ever clears it, so every I/O to the array stalls permanently once _wait_barrier() sees it stuck at 1. This used to be harmless: level_store() called mddev_resume() right after pers->run(), which called raid1_quiesce(mddev, 0) and cleared array_frozen back to 0 regardless of what raid1_takeover() set. Commit b39f35ebe86d ("md: don't quiesce in mddev_suspend()") removed that quiesce(mddev, 0) call, so the pre-set now sticks. setup_conf() already zero-initializes the new r1conf via kzalloc, so just don't set array_frozen here. Same class of bug as commit 892da88d1cd9 ("md/raid10: fix a 'conf->barrier' leakage in raid10_takeover()"), also triggered by b39f35ebe86d.

Affected packages

Ecosystem Package Introduced Fixed