CVE-2026-72477

The CVE-2026-72477 vulnerability in the NTFS3 kernel driver (merged in kernel 5.15) isn't a one-off coding mistake—it is a case study in how diagnostic infrastructure gets repurposed as error handling, and then persists as technical debt until someone files a CVE. The root cause: a developer added WARN_ON() in a call path where calling _ntfs_bad_inode() "wasn't safe" at that moment—but established no fallback, no tracking ticket, and no explicit timeline for when it would become safe. Later, a separate commit made _ntfs_bad_inode() safe for that call site. The second developer never cross-referenced the first, and the WARN_ON remained for months or years, generating stack traces that satisfied nobody and prevented nothing. The fix is trivial—replace WARN_ON with _ntfs_bad_inode()—but the institutional failure is structural. The pattern matters more than this specific inode. WARN_ON was designed to document "this should never happen" for developers debugging kernel internals. When used as a substitute for error-state propagation, it creates a false sense of acknowledgment without any security boundary. The kernel continues operating on an inconsistent inode, and nothing in the toolchain flags this as accumulating debt. There is no mechanism to mark a WARN_ON as a "placeholder pending condition X" that auto-expires or alerts when the prerequisite is resolved. The CVSS 9.8 versus EPSS 0.005 gap reflects this: the blast radius of arbitrary filesystem metadata corruption is real, but the trigger conditions are narrow enough that weaponization is difficult in practice. The remediation priority should be driven not by exploit probability but by the failure mode—once triggered, the corruption propagates upward through every file operation on that inode with no user-visible indicator. Replace every WARN_ON in security-sensitive paths with proper error propagation, and treat the diagnostic itself as the vulnerability when no fallback exists. Audit your newer filesystem drivers (NTFS3, any drivers merged post-5.15) for WARN_ON density in error-handling paths. High diagnostic density without corresponding error returns is a proxy for incomplete error-state design—technical debt that will calcify into vulnerabilities exactly like this one.

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