CVE-2026-72197

CVE-2026-72197 is a buffer overread in the NTFS3 driver's DeleteIndexEntryAllocation function. The vulnerability occurs when processing a crafted NTFS image during mount: the code performs a memmove using a length value derived from index entry metadata without validating that this length stays within bounds, causing the operation to walk past the destination buffer into adjacent kernel memory. The result is a write-what-where primitive triggered by mounting a malicious image—an attack surface that is documented, supported, and routinely automated, not theoretical. The fix is trivial: the same bounds check already exists in DeleteIndexEntryRoot, the sibling function handling the root variant of the same index operation. Copying five lines of validation from one function to the other closes the gap. What makes this worth your attention isn't the patch—it's the pattern. This is the third time in fifteen years we've seen this exact failure mode surface in a newly-merged kernel subsystem. USB drivers circa 2005-2010, networking stacks circa 2012-2016, and now filesystem drivers in 2026 all exhibit the same anatomy: correct defensive code in one code path, absent in its semantic sibling, discovered after merge. The NTFS3 driver was developed externally by Paragon and merged into mainline in 2021. Its post-merge history shows a pattern of defensive parity gaps—boundaries that should have been checked, sizes that should have been validated—accumulating faster than they're being retired. The EPSS score of 0.18% cited for this vulnerability is miscalibrated for this context. EPSS models network-adjacent exploitation; this vulnerability triggers during mount, a mundane local operation. The attack surface is not theoretical—it is exactly how filesystem vulnerabilities in this class are exploited in practice. The detection gap is structural, not procedural. Existing static analysis tools like Smatch and Sparse check types, uninitialized variables, and simple bounds violations. None check whether conceptually identical operations across separate functions have diverged in their defensive checking. Telling reviewers to "check sibling paths for equivalent guards" creates a cognitive burden that scales poorly and has failed to prevent recurrence across three different subsystems. What you should do: verify your kernels are running the patched version (the fix is in fs/ntfs3/index.c, the bounds check before the memmove call in DeleteIndexEntryAllocation). If you're maintaining downstream kernels or derivatives, audit the surrounding index entry functions for similar parity gaps—the root variant had the check, the allocation variant did not, and there may be other such pairs in the driver. Beyond this specific CVE, consider whether your review processes have any mechanism to flag defensive pattern divergence between functions handling conceptually identical operations. The pattern will recur unless the structural gap is addressed.

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