Description
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.
Published: 2026-09-17
Score: n/a
EPSS: < 1% Very Low
KEV: No
Impact: Kernel Crash (Denial of Service)
Action: Patch
AI Analysis

Impact

A bug in the Linux kernel’s RAID1 driver causes an Oops when a new redundant disk is added to an existing RAID1 array that has serialization policy enabled. The driver skips initializing a required field, which the wait_for_serialization routine later dereferences, leading to a local kernel panic. This results in a denial‑of‑service condition for the host system until a reboot or other recovery. The weakness is an example of improper initialization of a critical data structure.

Affected Systems

The vulnerability affects only the Linux kernel. It was observed with kernel version 7.1.3 when adding a new rdev to an existing RAID1 array with the serialize_policy attribute set to 1. Older kernel releases prior to the patch do not exhibit the symptom, and the issue is mitigated in later kernel releases where the initialization path has been corrected.

Risk and Exploitability

The EPSS score is reported less than 1%, indicating a very low probability of exploitation. The vulnerability is not currently listed in the CISA KEV catalog. The attack requires privileged local access to modify a RAID configuration, so the most likely exploitation path is through direct interaction with the host. The defect causes a crash rather than privilege escalation or data exfiltration, but an attacker who can trigger the bug can cause a denial‑of‑service attack on the affected system.

Generated by OpenCVE AI on September 19, 2026 at 13:49 UTC.

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

  • Update the Linux kernel to a patched release that includes the fix for the RAID1 serialization bug.
  • If a kernel upgrade is not immediately possible, avoid adding new redundant disks to existing RAID1 arrays while the serialize_policy attribute is enabled; alternatively, disable the serialize_policy sysfs attribute to prevent the race condition.
  • Continuously monitor dmesg and system logs for Oops messages related to raid1 or md_mod and investigate any unexpected kernel panics promptly.

Generated by OpenCVE AI on September 19, 2026 at 13:49 UTC.

Tracking

Sign in to view the affected projects.

Advisories
Source ID Title
Debian DLA Debian DLA DLA-4817-1 linux-6.12 security update
Debian DSA Debian DSA DSA-6528-1 linux security update
History

Sat, 19 Sep 2026 14:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-665

Thu, 17 Sep 2026 16:30:00 +0000

Type Values Removed Values Added
Description 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.
Title md/raid1: create serial pool adding rdev to array with serialize_policy=1
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-09-17T16:09:21.198Z

Reserved: 2026-09-11T19:38:34.809Z

Link: CVE-2026-90385

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-09-17T17:17:37.880

Modified: 2026-09-17T17:17:37.880

Link: CVE-2026-90385

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-09-19T14:00:15Z

Weaknesses