CVE-2025-71225
mediumCVSS v3 Base Score
5.3
CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:H
EPSS Score
0.0%
Exploitation probability in 30 days
Top 94% most likely to be exploited
Attack Characteristics
Attack Vector
Local
Attack Complexity
High
Privileges Required
Low
User Interaction
None
Confidentiality
Low
Integrity
None
Availability
High
Vulnerability Report
Generated by CyberWatcher
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.
CWE
CWE-367Affected Products
Red Hat Enterprise Linux 10Red Hat Enterprise Linux 6Red Hat Enterprise Linux 7Red Hat Enterprise Linux 8Red Hat Enterprise Linux 9