CVE-2025-71225 in Linux
Summary
by MITRE • 02/18/2026
In the Linux kernel, the following vulnerability has been resolved:
md: suspend array while updating raid_disks via sysfs
In raid1_reshape(), freeze_array() is called before modifying the r1bio memory pool (conf->r1bio_pool) and conf->raid_disks, and unfreeze_array() is called after the update is completed.
However, freeze_array() only waits until nr_sync_pending and (nr_pending - nr_queued) of all buckets reaches zero. When an I/O error occurs, nr_queued is increased and the corresponding r1bio is queued to either retry_list or bio_end_io_list. As a result, freeze_array() may unblock before these r1bios are released.
This can lead to a situation where conf->raid_disks and the mempool have already been updated while queued r1bios, allocated with the old raid_disks value, are later released. Consequently, free_r1bio() may access memory out of bounds in put_all_bios() and release r1bios of the wrong size to the new mempool, potentially causing issues with the mempool as well.
Since only normal I/O might increase nr_queued while an I/O error occurs, suspending the array avoids this issue.
Note: Updating raid_disks via ioctl SET_ARRAY_INFO already suspends the array. Therefore, we suspend the array when updating raid_disks via sysfs to avoid this issue too.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 05/22/2026
The vulnerability described in CVE-2025-71225 affects the Linux kernel's md (multi-device) subsystem, specifically within the RAID1 implementation where array reshaping operations occur. This issue stems from improper synchronization during the modification of RAID disk configurations through the sysfs interface, creating a race condition that can lead to memory corruption and system instability. The flaw manifests when the system attempts to update the raid_disks parameter while I/O operations are actively queued, particularly during error handling scenarios where I/O errors cause additional buffering operations.
The technical implementation of this vulnerability involves the raid1_reshape() function which employs freeze_array() to temporarily halt I/O operations before updating critical data structures including the r1bio memory pool and the raid_disks configuration. However, the freeze_array() mechanism has a fundamental limitation in its synchronization approach as it only waits for nr_sync_pending and (nr_pending - nr_queued) counters to reach zero. This approach fails to account for the fact that I/O errors can increment the nr_queued counter while simultaneously queuing r1bio structures to either retry_list or bio_end_io_list for later processing. When these queued r1bios are eventually processed, they reference memory structures that were allocated with the previous raid_disks value, creating a mismatch between the expected and actual memory layout.
The operational impact of this vulnerability extends beyond simple memory corruption to potentially compromise system stability and data integrity. When free_r1bio() attempts to release r1bios back to the memory pool after processing, it accesses memory locations that may have been reallocated or freed due to the updated raid_disks configuration. This out-of-bounds memory access can cause kernel panics, data corruption, or denial of service conditions that affect the entire storage subsystem. The vulnerability is particularly concerning because it occurs during routine maintenance operations such as array expansion or contraction, which are common in production environments where storage management is frequently performed. The issue is further exacerbated by the fact that only normal I/O operations can increase the nr_queued counter during error conditions, making the race window more predictable but still dangerous.
The mitigation strategy implemented in the kernel fix addresses this vulnerability by ensuring that the array is suspended during raid_disks updates via sysfs, similar to the existing behavior for ioctl SET_ARRAY_INFO operations. This suspension prevents new I/O operations from being queued while the configuration update is in progress, eliminating the race condition entirely. The solution aligns with established security practices for managing concurrent access to shared resources and follows the principle of least privilege by ensuring that configuration changes cannot occur while active I/O operations are pending. This approach also relates to the Common Weakness Enumeration category CWE-362, which addresses race conditions in concurrent systems, and maps to ATT&CK technique T1499.001 for unauthorized modification of system resources. The fix represents a defensive programming approach that prevents the specific race condition where memory pool management becomes inconsistent with the actual array configuration, thereby maintaining the integrity of kernel memory management structures during dynamic configuration changes.