CVE-2026-90275 in Linux
Summary
by MITRE • 09/17/2026
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.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/17/2026
The Linux kernel's device-mapper RAID subsystem contains a logic error within the raid1_takeover function that results in permanent input/output stalls for affected storage arrays. This vulnerability stems from an improper state management sequence during the takeover of one RAID level to another, specifically when transitioning to or operating as RAID-1. The core technical flaw lies in the assignment of the array_frozen flag within the r1conf structure. When raid1_takeover is invoked, it sets conf->array_frozen to 1 on the newly allocated configuration context. Under normal operational circumstances, this state was previously neutralized by a subsequent call to mddev_resume which triggered raid1_quiesce with a zero argument, effectively resetting array_frozen back to its inactive state. However, a prior commit identified as b39f35ebe86d titled "md: don't quiesce in mddev_suspend()" removed the explicit quiesce call from the suspension path. This change inadvertently broke the dependency chain that previously cleared the frozen flag, leaving array_frozen permanently set to 1 for any array undergoing this specific takeover process.
The operational impact of this vulnerability is severe and results in a complete denial of service for the affected storage device. Because the array_frozen flag remains stuck at one, every subsequent I/O operation directed at the RAID-1 array encounters a barrier wait condition that never resolves. The _wait_barrier function detects the frozen state and blocks further processing indefinitely. Consequently, any application or system process attempting to read from or write to this storage volume will hang until the kernel is rebooted or the device is manually removed and re-added under specific conditions that might reset the configuration. This effectively renders the data on the array inaccessible for the duration of the session, causing significant disruption to services relying on that storage infrastructure.
This issue represents a classic state leakage vulnerability where initialization logic fails to account for changes in surrounding control flow paths. The root cause is not an incorrect initial value since setup_conf already zero-initializes the r1conf structure via kzalloc, but rather the unnecessary explicit setting of array_frozen to one which overrides that safe default and persists due to the removal of the cleanup routine. This class of bug mirrors a similar issue found in raid10_takeover regarding barrier leakage, both triggered by the same refactoring commit b39f35ebe86d. The vulnerability aligns with CWE-472, which describes external control of assumption verification failures, as the code assumes that subsequent operations will reset internal state flags to safe defaults without verifying if those assumptions still hold after architectural changes. In terms of MITRE ATT&CK mapping, this can be categorized under T1505.003 Server Software Component: Stored Payload or more broadly within persistence mechanisms where system availability is compromised through resource exhaustion and service disruption, though it is primarily a reliability defect rather than an exploitable attack vector for privilege escalation.
Mitigation strategies focus on correcting the code logic to ensure state consistency regardless of surrounding function calls. The primary resolution involves removing the explicit assignment of conf->array_frozen = 1 within raid1_takeover since the structure is already zero-initialized by setup_conf, thereby relying on the default safe state. Alternatively, if retaining the flag setting is necessary for specific logical paths, a corresponding reset mechanism must be reintroduced in mddev_resume or an equivalent control path to ensure array_frozen is cleared before I/O operations proceed. System administrators should apply kernel patches that include this fix immediately upon availability. For environments where patching is not immediately feasible, monitoring storage logs for persistent I/O waits and ensuring regular backups are available can help mitigate the risk of prolonged data unavailability resulting from this defect.