Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.8",
  "pubDate": "2026-09-11T20:19:39.540Z",
  "pubdate": "2026-09-11T20:19:39.540Z",
  "executiveSummary": "A logical error in the Linux kernel RAID10 implementation has introduced a severe vulnerability leading to silent data corruption. The issue stems from an inverted boolean assignment during a refactoring of the md_bitmap_start_sync logic.\nThis vulnerability specifically affects RAID10 arrays utilizing internal bitmaps under degraded conditions. When a device is recovered while other mirrors remain missing, the kernel incorrectly notifies the bitmap subsystem that the array is no longer degraded. This causes the system to prematurely clear synchronization bits for missing devices.\nThe primary risk is silent data corruption: when previously failed disks are re-added, the RAID10 recovery process erroneously skips necessary synchronization, incorrectly marking stale data as 'In_sync'.\nThis flaw requires no specific attacker interaction, as it is a systemic reliability failure triggered by standard RAID maintenance operations (disk failure and re-addition). The impact is critical, as it bypasses data integrity mechanisms, leading to inconsistencies between mirror pairs that are not reported by the storage layer.",
  "technicalDetails": "The root cause of this vulnerability is an incorrect boolean assignment within the raid10_sync_request() function of the Linux kernel's md/raid10 driver. During the conversion of the 'still_degraded' variable from an integer type to a boolean type, the logic was inadvertently inverted. Specifically, the assignment 'still_degraded = 1' was refactored to 'still_degraded = false'.\nIn the context of RAID10 operation, 'still_degraded' is intended to communicate to the bitmap subsystem whether the array will remain in a degraded state after the current synchronization/recovery process completes. By setting this to 'false' while the array is actually still degraded, the kernel incorrectly signals that all regions are accounted for and that the associated bitmap bits can be cleared.\nThe attack flow/failure scenario proceeds as follows: 1) One or more disks in the RAID10 array fail, placing the array in a degraded state. 2) The array continues to accept writes to the degraded volume; these writes are tracked by the internal bitmap. 3) A device recovery operation is initiated. During this process, raid10_sync_request() incorrectly reports 'still_degraded = false' to md_bitmap_start_sync(). 4) The bitmap subsystem clears the bits that were meant to track the regions needing recovery for the still-missing disks. 5) When the missing disks are re-added, the recovery logic checks the bitmap, observes no pending work (due to the previously cleared bits), and marks the disks as 'In_sync' without performing the necessary data reconstruction.\nThis results in the newly added disks holding stale, inconsistent data, while the kernel reports them as healthy. This constitutes silent data corruption because the filesystem or application expects the disk to be synchronized, but it contains outdated blocks. The vulnerability manifests without authentication or elevated privileges, as it is a latent defect in the storage driver's recovery orchestration. The issue persists across various RAID10 configurations where internal bitmaps are enabled to manage recovery, significantly impacting data integrity in multi-drive fault scenarios."
}