CVE-2026-45888: Linux Kernel RAID1 Memory Leak Vulnerability

CVE-2026-45888 Overview

CVE-2026-45888 is a memory leak vulnerability in the Linux kernel's md/raid1 subsystem. The flaw resides in the raid1_run() function, which calls setup_conf() to register a kernel thread via md_register_thread(). When raid1_set_limits() subsequently fails, the previously registered thread is never unregistered. This leaks the md_thread structure and the underlying thread resource on each failed initialization path.

The issue was identified through a prototype static analysis tool combined with manual code review. The fix adds an md_unregister_thread() call to the error path, aligning cleanup behavior with other error handlers in the same function.

Critical Impact
Repeated failures to bring up a RAID1 array can exhaust kernel memory by leaking md_thread structures and thread resources, degrading host stability over time.

Affected Products

Linux kernel md/raid1 driver (multiple stable branches)
Systems using software RAID1 arrays managed through mdadm
Distributions shipping vulnerable kernel versions prior to the patches in commits 6abc7d5d, b37588b0, c94fd6e8, and ec10e3dc

Discovery Timeline

2026-05-27 - CVE-2026-45888 published to NVD
2026-05-27 - Last updated in NVD database

Technical Details for CVE-2026-45888

Vulnerability Analysis

The Linux kernel's multiple-device (md) layer implements software RAID. During array initialization, raid1_run() invokes setup_conf() to allocate the RAID1 configuration. setup_conf() calls md_register_thread(), which allocates an md_thread structure and spawns a kernel thread used for background RAID work.

After the thread is registered, raid1_run() calls raid1_set_limits() to apply queue and device limits. If raid1_set_limits() returns an error, control jumps to the failure path without invoking md_unregister_thread(). The kernel thread continues to exist and the associated md_thread allocation is never freed.

Each failed raid1_run() invocation leaks one md_thread structure and its kernel thread. While a single occurrence is small, repeated array assembly failures, such as those triggered by misconfigured devices or fuzzing harnesses, accumulate leaked resources and reduce available kernel memory.

Root Cause

The root cause is missing cleanup in an error path [Memory Leak]. raid1_run() did not symmetrically unwind the resources acquired by setup_conf() when a later step failed. Other error paths in the same function correctly invoke md_unregister_thread(); the raid1_set_limits() failure branch was inconsistent.

Attack Vector

This vulnerability requires local privileges sufficient to assemble or reconfigure md RAID arrays, typically CAP_SYS_ADMIN. An attacker, or a buggy automation pipeline, that can repeatedly trigger failing RAID1 assembly causes incremental kernel memory exhaustion. The vendor advisory notes the issue was compile-tested only and discovered via static analysis, not active exploitation.

The vulnerability does not provide code execution or privilege escalation primitives. Impact is limited to resource exhaustion conditions affecting host availability.

No verified public proof-of-concept code is available. The fix is documented in upstream kernel commits 6abc7d5d, b37588b0, c94fd6e8, and ec10e3dc. See the Kernel Git Commit 6abc7d5d for the canonical patch.

Detection Methods for CVE-2026-45888

Indicators of Compromise

Growing kernel slab usage attributable to md_thread allocations without corresponding RAID1 arrays being active
Repeated mdadm --assemble or mdadm --create failures recorded in dmesg or journalctl referencing raid1_run or raid1_set_limits
Unexpected kernel threads named md*_raid1 persisting after failed array assembly

Detection Strategies

Monitor /proc/slabinfo for unexplained growth in kernel object caches associated with md thread structures
Audit kernel logs for repeated md/raid1 setup failures, which indicate the leak path is being triggered
Track running kernel threads through ps -eLf and correlate orphaned md* threads against active arrays listed in /proc/mdstat

Monitoring Recommendations

Establish baselines for kernel memory consumption on hosts that assemble md arrays at boot or via hotplug
Alert on host-level low-memory conditions correlated with elevated md subsystem error counts
Include kernel version inventory in vulnerability management to surface hosts running unpatched md/raid1 code

How to Mitigate CVE-2026-45888

Immediate Actions Required

Apply the upstream kernel patches referenced in commits 6abc7d5d, b37588b0, c94fd6e8, and ec10e3dc once distributed by your Linux vendor
Update to a stable kernel release that includes the md_unregister_thread() cleanup in raid1_run()
Restrict CAP_SYS_ADMIN and md array management to trusted administrative accounts

Patch Information

The fix adds md_unregister_thread() to the failure path that follows a raid1_set_limits() error in raid1_run(). This ensures the thread registered by setup_conf() is released, matching the behavior of other error branches. Patch references: Kernel Git Commit 6abc7d5d, Kernel Git Commit b37588b0, Kernel Git Commit c94fd6e8, and Kernel Git Commit ec10e3dc.

Workarounds

Reboot affected hosts to reclaim leaked md_thread allocations until patched kernels are deployed
Avoid scripted retry loops that repeatedly invoke mdadm against arrays known to fail raid1_set_limits()
Validate underlying block device health and configuration before calling mdadm --assemble to reduce the rate of failing initialization paths

bash

# Verify the running kernel and md module versions before and after patching
uname -r
modinfo raid1 | grep -E 'version|srcversion|filename'

# Inspect active md arrays and associated kernel threads
cat /proc/mdstat
ps -eLf | grep -E 'md[0-9]+_raid1'