CVE-2026-89558

What it actually does

In raid10_sync_request the conversion of still_degraded from int to bool inverted the assignment, so md_bitmap_start_sync is called with degraded==false while a mirror is still missing; this clears bitmap bits that the absent device requires, allowing subsequent recovery to skip regions and leave the re-added device marked In_sync with stale data, resulting in silent corruption.

Why it matters to the business

RAID10 arrays on affected kernels can silently corrupt data during recovery after multiple disk failures, leading to undetected data loss, application errors, and potential regulatory or operational impact in storage-heavy environments.

How an attack unfolds

An attacker with local or network access that can induce or observe degraded RAID10 states (for example by forcing disk removal or waiting for natural failures) writes to the array while two mirrors are down, then triggers re-add and recovery; the inverted flag causes bitmap bits to be cleared, so the second device skips all writes performed while degraded and surfaces with stale data.

How to fix it

Apply the upstream fix that restores the correct still_degraded=true assignment in raid10_sync_request (the same logic already present in raid1); rebuild and boot the corrected kernel on all affected systems before performing any RAID recovery operations.

How to confirm the fix worked

Confirm the patch is present by inspecting the raid10_sync_request function for the line still_degraded=true inside the loop that checks remaining degraded mirrors; after upgrade, re-run the supplied reproducer and verify that mismatch_cnt remains zero and recovery actually copies the expected regions.

Typical attack path

1. Cause or wait for two disks (one from each mirror pair) to be removed from a near-layout RAID10 array with an internal bitmap
2. Perform writes to the degraded array
3. Re-add the failed disks and allow the kernel recovery thread to run
4. Observe that recovery completes in milliseconds and subsequent array check reports mismatches or application data differs

How to detect it

Look in kernel logs for raid10 recovery events that complete in an unusually short time relative to the amount of data written while degraded; examine dmesg or syslog for md_bitmap and still_degraded references around the time of disk re-add events; compare mdadm --detail output showing In_sync flags against actual data checksums after recovery.

What your security team should do

• Prioritize kernel upgrade on any system using md/raid10 with internal bitmaps
• Temporarily avoid recovery of multi-disk failures until patched
• Enable regular array checks (echo check > /sys/block/mdX/md/sync_action) after any recovery on unpatched kernels
• Monitor EPSS and KEV status for changes that would accelerate patching timelines