CVE-2026-89558

A refactoring bug in the Linux kernel's md/raid10 driver inverted a boolean (still_degraded) in raid10_sync_request(), so when a device is recovered while its mirror pair is still missing, bitmap bits that the absent device needs are cleared prematurely. When the missing disk is later re-added, bitmap-based recovery sees every region written during the degraded period as already clean and skips it, marking the disk In_sync while it holds stale data. The result is silent data corruption on RAID10 arrays that ran degraded with an internal bitmap: the upstream reproducer shows mismatch_cnt of 262272 after 256 MiB of degraded writes, with 'recovery' completing in milliseconds because all writes are skipped. Any system running a kernel that contains the md-bitmap operations merge commit (fe6a19d40ceb) but lacks this fix is affected, though actual corruption requires the specific operational sequence of degraded writes followed by disk re-addition. The flaw is rated CVSS 3.1 9.8 (critical); no public proof of concept exists and no exploitation has been observed, but corruption can occur with no attacker involvement at all.

What to do: Patch to a kernel containing this fix as part of your normal update cycle. For any RAID10 array that ran degraded with writes and then had disks re-added on an affected kernel, do not trust the data: run an mdadm "check" and review mismatch_cnt, and treat any non-zero count as evidence of stale data requiring a full resync (remove/re-add the disk to force it) or restore from verified backups. RAID10 arrays that never ran in a degraded state with concurrent writes are not exposed to the corruption path, but should still be patched.