CVE-2026-89558 PUBLISHED

md/raid10: fix still_degraded being inverted in raid10_sync_request()

Assigner: Linux
Reserved: 11.09.2026 Published: 11.09.2026 Updated: 13.09.2026

In the Linux kernel, the following vulnerability has been resolved:

md/raid10: fix still_degraded being inverted in raid10_sync_request()

Commit fe6a19d40ceb ("md/md-bitmap: merge md_bitmap_start_sync() into bitmap_operations") converted still_degraded from int to bool, but inverted the assignment in the loop that checks whether the array will still be degraded after the current device is recovered: "still_degraded = 1" became "still_degraded = false".

As a result, recovering a device while another mirror is still missing calls md_bitmap_start_sync() with degraded == false, which clears bitmap bits that the still-missing device needs. When that device is re-added, its bitmap-based recovery finds the bits already cleared and skips every region written while the array was degraded, so it is marked In_sync while holding stale data: silent corruption.

Reproducer (raid10 near=2, 4 disks, internal bitmap): - fail and remove one disk of each mirror pair - write to the degraded array - re-add both disks and let recovery finish - "check" reports mismatch_cnt=262272 after 256 MiB of degraded writes and file contents differ; the second disk's "recovery" completes in milliseconds because everything is skipped

The same conversion in raid1 got it right (still_degraded = true). Restore the correct value.

Metrics

CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
CVSS Score: 9.8

AV:N - md RAID10 commonly backs NAS/SAN volumes exported over NFS, ksmbd, iSCSI, and NVMe-oF. Remote writes during dual-degraded operation dirty the write-intent bitmap, and after buggy recovery remote reads reach md_submit_bio()->raid10_read_request()->read_balance() and are served from the stale In_sync mirror without local shell access. AC:L - The inverted still_degraded assignment is deterministic in raid10_sync_request() whenever one member is recovered while another remains missing or Faulty. The documented fail/remove/write/re-add sequence needs no race or attacker-uncontrolled memory layout; write-intent bitmaps on RAID10 are a standard mdadm default, not a rare config. PR:N - Client I/O to an exported RAID10 LUN needs no Linux UID or host capability: unauthenticated iSCSI/NVMe-oF and guest NFS/SMB writes reach md_submit_bio() and later read stale mirrors. md ioctls/sysfs fail/re-add use capable(CAP_SYS_ADMIN), but hot-spare recovery and storage-protocol I/O do not, so Privileges Required is None rather than High. UI:N - No victim click, mount, or confirmation is required. The attacker or automated storage clients issue ordinary reads and writes; md_check_recovery() and md_start_sync() invoke raid10_sync_request() from hot-spare activation or disk re-add as kernel background work. S:U - Silent corruption, stale-data disclosure, and volume unavailability remain inside the host kernel and the md RAID10 array. The bug does not escape a VM, bypass an IOMMU, or otherwise cross a separate security authority. C:H - raid10_spare_active() sets In_sync on the re-added member while it still holds stale sectors. read_balance() then returns that disk's prior contents, including previously freed blocks that the current filesystem layout may assign to other users' or overwritten files, disclosing unauthorized data. I:H - md_bitmap_start_sync() is called with degraded=false, clearing NEEDED bits the still-missing mirror requires. That device is marked In_sync after skipping dirty regions; later read-modify-write of the stale data is mirrored to all copies, permanently corrupting filesystem and user data. A:H - Stale filesystem metadata served from the wrongly In_sync mirror drives remount-ro, XFS shutdown, or panic on errors=panic, and skipped bitmap recovery leaves dirty regions unrestored, denying availability of the RAID10 volume and any boot or data filesystems on it.

Product Status

Vendor Linux
Product Linux
Versions Default: unaffected
  • affected from fe6a19d40ceb44281905485f56dda715e3214e0e to 9bb8da6ecb330a5b1ac9b96f1e55f134a7aef1d4 (excl.)
  • affected from fe6a19d40ceb44281905485f56dda715e3214e0e to 0efabe6229dc683dbf6eeebd0f9fddc7971ed420 (excl.)
  • affected from fe6a19d40ceb44281905485f56dda715e3214e0e to 00449d752bee9c8787f42ea1bf533a9fb17f9b6b (excl.)
  • affected from fe6a19d40ceb44281905485f56dda715e3214e0e to 47f1441b281decde6954a2fa82b4131637d685ac (excl.)
Vendor Linux
Product Linux
Versions Default: affected
  • Version 6.12 is affected
  • unaffected from 0 to 6.12 (excl.)
  • unaffected from 6.12.109 to 6.12.* (incl.)
  • unaffected from 6.18.50 to 6.18.* (incl.)
  • unaffected from 7.2.4 to 7.2.* (incl.)
  • unaffected from 7.3-rc1 to * (incl.)

References