The vulnerability originates from an incorrect boolean assignment in the RAID10 sync process. During a disk recovery, the flag that indicates whether an array will remain degraded is inverted, causing bitmap bits that should. When a previously missing disk is later re‑added, its recovery skips all regions written while the array was degraded, leaving stale or corrupt data written to the array. The primary impact is a breach of data integrity; the flaw does not provide remote code execution, denial of service, or any other external impact.

All Linux kernel versions released before the kernel commit (fe6a19d40ceb) that fixed the inverted assignment are affected. This includes every distribution’s default kernel that contains the buggy RAID10 code. Because the affected code resides in the core md RAID subsystem, any system using the Linux kernel for RAID10 with an internal bitmap is at risk, regardless of distribution.

The CVSS score of 4.4 indicates a moderate risk level. The EPSS score is less than 1%, indicating a very low likelihood of exploitation, and the vulnerability is not listed in the CISA KEV catalog. The likely attack vector is local; an attacker would need the ability to remove and later re‑add a disk from a mirrored RAID10 array while the array is in a degraded state. This typically requires physical access, elevated privileges, or a failure scenario that triggers disk removal. Because the vulnerability exploits a filesystem state change rather than a code path that can be invoked over a network, remote exploitation is unlikely without additional privileged access.