CVE-2025-71225
Received Received - Intake
Use-After-Free Vulnerability in Linux md RAID1 Array Update via sysfs

Publication date: 2026-02-18

Last updated on: 2026-03-18

Assigner: kernel.org

Description
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.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-02-18
Last Modified
2026-03-18
Generated
2026-05-07
AI Q&A
2026-02-18
EPSS Evaluated
2026-05-05
NVD
CVE-2025-71225
EUVD
EUVD-2025-207829
Affected Vendors & Products
Showing 10 associated CPEs
Vendor Product Version / Range
linux linux_kernel 3.10
linux linux_kernel 3.10
linux linux_kernel 3.10
linux linux_kernel 6.19
linux linux_kernel 6.19
linux linux_kernel 6.19
linux linux_kernel From 6.13 (inc) to 6.18.10 (exc)
linux linux_kernel From 3.10.1 (inc) to 6.12.70 (exc)
linux linux_kernel From 3.4.59 (inc) to 3.5 (exc)
linux linux_kernel From 3.9.7 (inc) to 3.10 (exc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-367 The product checks the state of a resource before using that resource, but the resource's state can change between the check and the use in a way that invalidates the results of the check.
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability exists in the Linux kernel's md (multiple device) subsystem, specifically when updating the raid_disks parameter via sysfs in a RAID1 array.

The issue arises because the function freeze_array() is intended to pause the array before modifying certain memory pools and raid_disks values, but it only waits for some I/O operations to complete. When an I/O error occurs, some queued bio structures (r1bios) remain unreleased because freeze_array() unblocks too early.

As a result, the system may update raid_disks and memory pools while still holding references to old-sized r1bios. Later, when these r1bios are released, the kernel may access memory out of bounds or release memory to the wrong pool, potentially causing memory corruption or instability.

To fix this, the array is suspended during updates via sysfs to ensure all relevant I/O operations complete before changes are made.


How can this vulnerability impact me? :

This vulnerability can lead to memory corruption or instability in the Linux kernel's RAID1 subsystem when updating the raid_disks parameter via sysfs.

Such memory corruption could cause system crashes, data loss, or unpredictable behavior in systems relying on RAID1 arrays managed by the affected kernel versions.

If your system uses RAID1 arrays and updates raid_disks via sysfs without suspending the array, it may be vulnerable to these issues.


How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:

I don't know


How can this vulnerability be detected on my network or system? Can you suggest some commands?

I don't know


What immediate steps should I take to mitigate this vulnerability?

To mitigate this vulnerability, suspend the RAID array when updating raid_disks via sysfs. Suspending the array avoids the issue caused by queued r1bios being released after the raid_disks and mempool have been updated.

Note that updating raid_disks via ioctl SET_ARRAY_INFO already suspends the array, so ensure that similar suspension is applied when updating raid_disks through sysfs.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart