Cloudanix VulnDB

CVE-2026-90385

None

CVSS

—

EPSS

0.2%

Published

Sep 17, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A flaw in Linux storage software can crash servers when a new disk is added to certain mirrored storage setups, leading to unexpected downtime.

Exploitation
Local Privilege
Attacker needs
High Privilege
Complexity
Low
Impact
Denial Of Service
Component
OS kernel
Class
Memory Corruption
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

Uninitialized rdev->serial pointer dereference in raid1 when serialize_policy=1, leading to invalid spinlock access and kernel oops during I/O on arrays where a new rdev was hot-added.

Why it matters to the business

Unexpected kernel crashes on systems using Linux software RAID1 with serialize_policy enabled, causing downtime and potential data unavailability until the system is restarted or the array is rebuilt.

How an attack unfolds

An attacker with sufficient privileges to add a new device to a RAID1 array triggers the missing serial pool initialization path in bind_rdev_to_array, causing subsequent I/O requests to hit wait_for_serialization on an invalid pointer and crash the kernel.

How to fix it

Apply the upstream kernel patch that ensures mddev_create_serial_pool is called correctly for new rdevs in bind_rdev_to_array when serialize_policy is enabled; rebuild and deploy the fixed kernel to all affected systems.

How to confirm the fix worked

Confirm the presence of the corrected condition check inside bind_rdev_to_array and mddev_create_serial_pool; test by adding an rdev to a serialize_policy-enabled RAID1 array and verifying no oops occurs on subsequent I/O.

Typical attack path

  1. Obtain local access or compromise a process with permissions to manage md devices
  2. Create or attach a new rdev to an existing RAID1 array that has serialize_policy set
  3. Issue I/O that reaches raid1_make_request while serialize_policy is active
  4. Trigger the uninitialized serial access and induce kernel panic

How to detect it

Review kernel logs for oops entries referencing _raw_spin_lock_irqsave, wait_for_serialization, and raid1_make_request around the time an rdev was added to a RAID1 array; correlate with mdadm or udev events that attach new devices.

What your security team should do

  • Prioritize kernel updates on all systems using md RAID1 with serialize_policy
  • Audit RAID configurations for serialize_policy usage and document exposure
  • Monitor for kernel oops reports involving raid1 and wait_for_serialization

The record

In the Linux kernel, the following vulnerability has been resolved: md/raid1: create serial pool adding rdev to array with serialize_policy=1 The following bug has been observed with kernel 7.1.3 after adding a new rdev to an existing RAID1 array with serialize_policy enabled: Oops: 0002 [#1] CPU: 0 UID: 0 PID: 19639 Comm: ext4lazyinit Not tainted 7.1.3-1-default RIP: _raw_spin_lock_irqsave+0x27/0x50 CR2: 0000000000004960 Call Trace: wait_for_serialization+0xb9/0x260 [raid1] raid1_make_request+0x762/0xaff [raid1] md_handle_request+0x1c9/0x2e0 [md_mod] The raid1.c code calls wait_for_serialization() if the MD_SERIALIZE_POLICY is set, and wait_for_serialization assumes that rdev->serial is initialized. Normally this will be the case for arrays that have the serialize_policy sysfs attribute set to 1. But when a new rdev is added to an existing array in bind_rdev_to_array(), the condition at mddev_create_serial_pool() causes creation of rdev->serial to be skipped. Fix it.

Affected packages

Ecosystem Package Introduced Fixed