CVE-2026-72195 is a validation failure in the Linux NTFS3 driver's UpdateResidentValue function. When processing on-disk MFT records, the driver calculates attribute offsets as aoff + dlen (attribute offset plus data length). Under specific malformed input conditions, this addition underflows to approximately 4GB, corrupting the attribute's data_size field. This corrupted value then poisons offset calculations for every subsequent attribute on the same MFT record — the failure is lateral, not vertical. Attributes following the malformed entry become inaccessible or misread not because they are corrupted, but because the driver is now operating on garbage offsets derived from the initial corruption.
What makes this worth your attention is the architectural failure that created it. The NTFS3 driver contains a downstream safety check in mi_enum_attr() that correctly detects the corrupted data_size — but only when attributes are accessed through the enumeration path. Direct attribute reads by name or handle bypass this check entirely. The existence of this catch created a false confidence: developers added one downstream guard rather than validating at the source, reasoning that 'we already handle that.' The fix in UpdateResidentValue (validating aoff against data_off at the source) should have been the default architecture from the start.
The commercial origin of this driver matters. Paragon developed NTFS3 for commercial deployments where NTFS partitions are pre-validated by Windows before Linux mounts them. That implicit trust assumption did not survive the open-source handoff. When upstreamed to the kernel, the driver retained its downstream catch but lost the threat model that made it acceptable. Every direct attribute read became a trust boundary that was never audited because the catch 'already handled' validation — for one code path, not all.
The EPSS score of 0.00164 reflects current runtime exploitability, but it measures the wrong dimension. The attack surface is measured in persistence, not exploitability: the corrupted data_size lives in the MFT record after mount fails, meaning future code paths (driver updates, recovery tools, Windows accessing the same volume) inherit the trigger condition without the downstream safety net. The 'real' exposure window extends forward in time, not across current attack surfaces.
For your audit: identify other direct attribute reads in NTFS3 that bypass mi_enum_attr(). Treat the existence of any downstream catch as a red flag for missing source validation, not evidence that the trust boundary is handled. The same pattern — computed attribute values stored without cross-validating against sources — appears in f2fs, ext4, and btrfs at different points. This is a genealogical vulnerability class in filesystem drivers, not an isolated arithmetic error.