CVE Catalog

CVE-2026-90275

Unknown
Published: Translated: NVD NIST

Summary

In the Linux kernel, the md/raid1 subsystem's raid1_takeover() sets conf->array_frozen = 1 on the newly allocated r1conf and never clears it, so every I/O to the array stalls permanently once _wait_barrier() sees it stuck at 1. This used to be harmless because level_store() called mddev_resume(), but commit b39f35ebe86d removed that call. The fix simply does not set array_frozen in raid1_takeover().

Risk Assessment

Causes permanent I/O stalls on a RAID1 array after takeover, leading to data unavailability and potential data loss. Occurs on systems with a kernel containing commit b39f35ebe86d.

Recommendation

Update the Linux kernel to a version containing the fix that removes setting array_frozen in raid1_takeover(). If a RAID1 array has already been taken over and I/O stalled, recreating the array may be required.

Other vulnerabilities in Linux kernel

See all
Original NVD description (English source)

In the Linux kernel, the following vulnerability has been resolved: md/raid1: don't set array_frozen in raid1_takeover() raid1_takeover() sets conf->array_frozen = 1 on the newly-allocated r1conf and nothing ever clears it, so every I/O to the array stalls permanently once _wait_barrier() sees it stuck at 1. This used to be harmless: level_store() called mddev_resume() right after pers->run(), which called raid1_quiesce(mddev, 0) and cleared array_frozen back to 0 regardless of what raid1_takeover() set. Commit b39f35ebe86d ("md: don't quiesce in mddev_suspend()") removed that quiesce(mddev, 0) call, so the pre-set now sticks. setup_conf() already zero-initializes the new r1conf via kzalloc, so just don't set array_frozen here. Same class of bug as commit 892da88d1cd9 ("md/raid10: fix a 'conf->barrier' leakage in raid10_takeover()"), also triggered by b39f35ebe86d.

Vulnerability data from NVD (NIST) · CISA KEV · EPSS