CVE-2025-22126: Linux Kernel Race Condition Vulnerability

CVE-2025-22126 Overview

CVE-2025-22126 is a Use-After-Free (UAF) vulnerability in the Linux kernel's MD (Multiple Device) driver subsystem. The flaw exists in the iteration logic of the all_mddevs list during system reboot (md_notify_reboot()) and module exit (md_exit()) operations. When using list_for_each_entry_safe to traverse the list of MD devices, a race condition can occur with concurrent deletion of the next mddev entry, leading to dereferencing freed memory.

Critical Impact

Local attackers with low privileges can exploit this race condition to potentially achieve arbitrary code execution or cause system crashes through memory corruption.

Affected Products

• Linux Kernel (multiple versions)
• Systems using MD/Software RAID functionality
• Debian-based distributions (see Debian LTS Announcement)

Discovery Timeline

• 2025-04-16 - CVE-2025-22126 published to NVD
• 2025-11-03 - Last updated in NVD database

Technical Details for CVE-2025-22126

Vulnerability Analysis

This vulnerability stems from improper synchronization when iterating over the all_mddevs linked list in the Linux kernel's MD driver. The MD subsystem manages software RAID arrays, and maintains a global list of all MD device structures. During critical operations like system reboot or module unloading, the kernel needs to iterate through all MD devices to perform cleanup operations.

The flaw occurs because list_for_each_entry_safe provides safety only against removal of the current element during iteration, not against removal of the next element. In a multi-threaded scenario, thread T1 may hold a reference to the current mddev and cache the next mddev pointer, while thread T2 concurrently removes and frees that next mddev. When T1 subsequently attempts to continue iteration, it dereferences the freed memory, resulting in a Use-After-Free condition.

The attack requires local access and the ability to trigger concurrent MD device operations during system reboot or module exit, making this primarily a local privilege escalation or denial-of-service vector.

Root Cause

The root cause is a race condition in the list iteration logic. The original implementation using list_for_each_entry_safe cached the "next" pointer without holding the spinlock, allowing another thread to delete and free that next entry before the iterating thread could access it. The old helper function for_each_mddev() previously grabbed the reference to the next mddev while holding the lock, preventing this race. The fix introduces mddev_put_locked(), a helper function similar to the approach used in md_seq_show(), which ensures proper reference counting while the lock is held.

Attack Vector

The attack vector is local, requiring an attacker to have low-privilege access to the system. The attacker must be able to:

1. Trigger MD device deletion operations (e.g., removing a software RAID array)
2. Simultaneously cause iteration over the all_mddevs list (e.g., during reboot notification or module operations)
3. Win the race condition to cause the UAF

The race window exists between when thread T1 releases the spinlock after caching the next pointer and when thread T2 completes the kfree(mddev2) operation. Successful exploitation could allow memory corruption leading to privilege escalation or kernel panic.

The vulnerability can be understood through the following sequence of operations:

Thread T1 (iterating):

• Acquires spinlock
• Gets reference to mddev1, caches pointer to mddev2 (next entry)
• Releases spinlock

Thread T2 (removing mddev2):

• Calls mddev_free on mddev2
• Acquires spinlock
• Removes mddev2 from list via list_del
• Releases spinlock
• Calls kfree(mddev2)

Thread T1 continues:

• Calls mddev_put(mddev1)
• Acquires spinlock
• Attempts to dereference mddev2->all_mddevs (freed memory - UAF)

Detection Methods for CVE-2025-22126

Indicators of Compromise

• Kernel panic or oops messages referencing MD driver functions such as md_notify_reboot or md_exit
• Unexpected system crashes during shutdown or reboot operations on systems with software RAID
• KASAN (Kernel Address Sanitizer) reports indicating use-after-free in MD subsystem
• Suspicious activity around MD device creation/deletion timing with system shutdown

Detection Strategies

• Enable KASAN in kernel builds to detect UAF conditions at runtime
• Monitor kernel logs (dmesg) for warnings or errors related to the MD subsystem during shutdown sequences
• Implement system monitoring for unexpected reboots or kernel panics on systems using software RAID
• Use kernel debugging tools like ftrace to monitor mddev_get, mddev_put, and list iteration functions

Monitoring Recommendations

• Deploy endpoint detection solutions that can monitor kernel-level memory operations
• Establish baseline behavior for MD device operations and alert on anomalies
• Configure centralized logging to capture kernel messages across the fleet
• Monitor for repeated system crashes that could indicate exploitation attempts

How to Mitigate CVE-2025-22126

Immediate Actions Required

• Update the Linux kernel to a patched version immediately
• Prioritize systems running software RAID (MD) configurations
• Review and apply patches from the kernel Git repository for affected versions
• Consider temporarily avoiding MD device modifications during planned reboots on unpatched systems

Patch Information

The Linux kernel maintainers have released patches that switch from list_for_each_entry_safe to list_for_each_entry and introduce a new helper function mddev_put_locked() to properly handle reference counting while holding the spinlock. This approach mirrors the existing safe pattern used in md_seq_show().

Multiple patch commits are available for different kernel branches:

• Kernel Git Commit 5462544
• Kernel Git Commit 8542870
• Kernel Git Commit ca9f84d
• Kernel Git Commit d69a23d
• Kernel Git Commit e2a9f73

Workarounds

• Limit local access to systems with software RAID configurations to trusted users only
• Implement strict access controls to prevent unauthorized users from manipulating MD devices
• Monitor and audit MD device operations, especially during system maintenance windows
• Consider using hardware RAID controllers instead of software RAID on critical systems until patching is complete

# Check current kernel version
uname -r

# Verify if MD module is loaded
lsmod | grep md_mod

# List active MD devices
cat /proc/mdstat

# Check for available kernel updates (Debian/Ubuntu)
apt update && apt list --upgradable | grep linux

# Check for available kernel updates (RHEL/CentOS)
yum check-update kernel