Instituto Nacional de ciberseguridad. Sección Incibe
Instituto Nacional de Ciberseguridad. Sección INCIBE-CERT

CVE-2025-71225

Gravedad:
Pendiente de análisis
Tipo:
No Disponible / Otro tipo
Fecha de publicación:
18/02/2026
Última modificación:
18/02/2026

Descripción

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> md: suspend array while updating raid_disks via sysfs<br /> <br /> In raid1_reshape(), freeze_array() is called before modifying the r1bio<br /> memory pool (conf-&gt;r1bio_pool) and conf-&gt;raid_disks, and<br /> unfreeze_array() is called after the update is completed.<br /> <br /> However, freeze_array() only waits until nr_sync_pending and<br /> (nr_pending - nr_queued) of all buckets reaches zero. When an I/O error<br /> occurs, nr_queued is increased and the corresponding r1bio is queued to<br /> either retry_list or bio_end_io_list. As a result, freeze_array() may<br /> unblock before these r1bios are released.<br /> <br /> This can lead to a situation where conf-&gt;raid_disks and the mempool have<br /> already been updated while queued r1bios, allocated with the old<br /> raid_disks value, are later released. Consequently, free_r1bio() may<br /> access memory out of bounds in put_all_bios() and release r1bios of the<br /> wrong size to the new mempool, potentially causing issues with the<br /> mempool as well.<br /> <br /> Since only normal I/O might increase nr_queued while an I/O error occurs,<br /> suspending the array avoids this issue.<br /> <br /> Note: Updating raid_disks via ioctl SET_ARRAY_INFO already suspends<br /> the array. Therefore, we suspend the array when updating raid_disks<br /> via sysfs to avoid this issue too.

Impacto