CVE-2026-72211

This vulnerability in the Linux NTFS driver exposes a fragile ordering assumption that was only survivable because the ENOSPC recovery path is rarely exercised during development. In ntfs_ir_reparent(), the code updates index root header fields before resizing the underlying buffer. When the resize fails with -ENOSPC, the recovery path runs against a header where allocated_size exceeds the actual resident value, and lookup validation correctly rejects it as corrupt. The fix reorders operations for the grow case—resize first, then update header—but preserves the original ordering for shrink and same-size operations. This asymmetry is not a complete resolution; it encodes a known fragility in the recovery path. The ntfs_inode_add_attrlist() function called during recovery makes an optimistic assumption: that it will never encounter a header where allocated_size exceeds the buffer. The patch protects this assumption rather than fixing it, leaving shrink operations with the same transient inconsistency window. What makes this analytically interesting is the historical pattern. This exact ordering failure has appeared in ext4 (CVE-2014-8116), xfs, and btrfs across the past decade. Each time, the failure mode is identical—header fields published before resize commits, recovery path encounters malformed state, corruption propagates downstream. The NTFS driver maintainers had no structural reason to be unaware of this class of bug; institutional knowledge simply doesn't transfer across subsystem boundaries. This is not primarily a testing gap—it's an organizational failure where code written by different authors at different times interacts badly because no one reviewed the composition. The recovery infrastructure in NTFS is aspirational rather than defensive. It only functions correctly when everything proceeds nominally. The narrow conjunction required to trigger this—reparent running, ENOSPC hit during resize, recovery then querying the corrupted header—partially explains why it survived so long, but that narrowness is evidence of how untested the failure paths are, not reassurance. Audit your NTFS environments for other attribute types (inode attribute lists, reparse points, security descriptors) that may have similar header-value couplings where header updates precede buffer operations. The ENOSPC path is not comprehensively tested in upstream kernel infrastructure—it surfaced via a qemu reproducer, not the kernel's own test suite.

Reviewed through automated stages and approved by a human before publication.