CVE-2026-64600
CVE-2026-64600 is a race condition in XFS reflink operations where stale data fork mappings produce incorrect `shared` values after ILOCK release and reacquisition. The vulnerability exists in the same logical operation where a prior fix addressed cow fork staleness — but that fix was never systematically applied to the adjacent data fork path. The technical mechanism: when `xfs_reflink_fill_cow_hole` or `xfs_reflink_fill_delalloc` releases the ILOCK to cycle through different locking states, the data fork mapping passed to these helpers can become stale. On reacquisition, the code uses the old mapping without revalidating it. This causes the `shared` field to be set incorrectly, which propagates into the refcount btree. Unlike purely in-memory state corruption, this affects persistent storage: direct I/O writes can target wrong physical blocks based on corrupted sharing information, corrupting data unrelated to the operation. What makes this notable is not the TOCTOU pattern itself, but what the partial fix reveals. The cow fork case was addressed with `xfs_find_trim_cow_extent` — a full re-query after lock reacquisition. The data fork case, when finally patched, used a different technique: sequence counter checking to detect staleness. Two different solutions for the same root cause in symmetric code paths, suggesting this wasn't one developer's oversight but likely represents work done at different times by different mental models — or simply the same developer moving on after addressing the immediate symptom. This vulnerability has lineage. CVE-2021-4154 and CVE-2022-4894 both involved similar partial coverage in XFS reflink — fixing cow fork while leaving data fork exposed. The pattern is documented in security circles but wasn't institutionalized into review checklists or static analysis rules. Each CVE was treated as incident-specific rather than pattern-generalized. What to check: if you're running an XFS version prior to the fix, look for `xfs_reflink_fill_cow_hole` and `xfs_reflink_fill_delalloc` callers. Verify that data fork mappings are revalidated after any ILOCK cycling within those functions — specifically, check whether a sequence counter or equivalent staleness check exists for the data fork path where the cow fork path has `xfs_find_trim_cow_extent`. The absence of symmetry between the two fork handling paths is the fingerprint of this bug. The blast radius is amplified because the refcount btree is central to XFS reflink's value proposition — deduplication, snapshots, and copy-on-write all depend on its correctness. Wrong `shared` values don't just cause transient errors; they corrupt the filesystem's core sharing metadata, potentially affecting operations far removed from the triggering write.
Reviewed through automated stages and approved by a human before publication.