CVE-2026-90275: md/raid1: don't set array_frozen in raid1_takeover()
In the Linux kernel, the following vulnerability has been resolved:
md/raid1: don't set arrayfrozen in raid1takeover()
raid1takeover() sets conf->arrayfrozen = 1 on the newly-allocated r1conf and nothing ever clears it, so every I/O to the array stalls permanently once waitbarrier() sees it stuck at 1.
This used to be harmless: levelstore() called mddevresume() right after pers->run(), which called raid1quiesce(mddev, 0) and cleared arrayfrozen back to 0 regardless of what raid1takeover() set. Commit b39f35ebe86d ("md: don't quiesce in mddevsuspend()") removed that quiesce(mddev, 0) call, so the pre-set now sticks.
setupconf() already zero-initializes the new r1conf via kzalloc, so just don't set arrayfrozen here.
Same class of bug as commit 892da88d1cd9 ("md/raid10: fix a 'conf->barrier' leakage in raid10takeover()"), also triggered by b39f35ebe86d.
Affected Software
Event History
Frequently Asked Questions
Which systems are exposed to the I/O stall?
The issue affects Linux md RAID1 arrays when raid1_takeover() is performed. Once the affected state is reached, subsequent I/O to that array can stall permanently.
What change made the previously harmless state become persistent?
Commit b39f35ebe86d removed the mddev_resume() quiesce call that had cleared array_frozen. As a result, the value set during takeover is no longer reset.
How can an affected array be recognized?
A practical indicator is that every I/O to the RAID1 array stalls permanently after the takeover operation. Source inspection can also identify the issue if raid1_takeover() sets conf->array_frozen while no later path clears it.