CVE-2026-72207

This vulnerability isn't a classic coding error — it's a subsystem coordination failure that allowed the Linux NTFS3 driver to produce filesystem states that its own repair tool subsequently rejects as corruption. When ntfs_resident_attr_resize() converts resident attributes to non-resident form under MFT record pressure, it apparently never validated that the resulting state would pass fsck.ntfs3's structural checks. The specific failure: zero-length $DATA attributes being converted to non-resident form, which fsck flags as invalid metadata. A normal write workload under MFT pressure can self-generate corruption without any malicious input. The CVSS of 9.8 reflects the severity correctly — this corrupts filesystems through ordinary operation, not exploitation. However, the EPSS of 0.00516 measures adversary-driven exploitation, not user-driven corruption, which is the actual failure mode here. The trigger condition (MFT exhaustion through intensive I/O) is common in database workloads, large file operations, and cluster computing environments, making this quietly widespread rather than exotic. The fix itself is trivial — exclude zero-length $DATA attributes from non-resident conversion. But the deeper issue is more significant. NTFS3 was reverse-engineered against Microsoft's implementation rather than built from a full specification, meaning the driver operates on inferred invariants rather than guaranteed ones. When fsck.ntfs3's validation rules tightened (likely aligning more closely with Microsoft's internal expectations), the driver's implicit assumptions broke. This wasn't a coordination failure between two valid perspectives — it was a correctness failure where the driver's edge-case behavior was never validated against the repair tool's expectations. Audit the other attribute conversion paths in ntfs3 for similar narrow assumptions. Any optimization or forced-conversion path that wasn't validated against current fsck semantics is a candidate for latent defects. The forced conversion paths in attribute compression, relocation, and similar pressure-handling mechanisms should be reviewed specifically. The broader question for the Linux NTFS stack is which other reverse-engineered subsystems operate on similarly incomplete inference about edge case behavior — this pattern suggests the answer is 'more than one'.

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