CVE-2026-72188

The CVSS 9.1 rating here is technically defensible, but it reflects a design flaw of the most dangerous kind: untrusted on-disk metadata escaping validation at the source. The core vulnerability is a trust boundary failure in ntfs_lookup_inode_by_name(), which reads values from an NTFS directory index and returns them to callers without sanitization. The MREF error bit exists to mark invalid references, but a crafted image can set that bit while populating the low bits with arbitrary pseudo-errno values. Callers that consume these values via MREF_ERR() receive garbage instead of the expected failure code, creating unpredictable kernel behavior downstream. The fix normalizes at the source—converting every error-marked MFT reference to ERR_MREF(-EIO)—rather than patching each caller. This is the correct architectural choice because it treats the function as a validation boundary rather than a dumb pass-through. Four separate call sites all failed to handle this edge case, which isn't negligence; it's a predictable consequence of an API that makes the secure path harder than the insecure one. The MREF API encodes error state into the same data structure as valid references, forcing callers to actively opt into validation via MREF_ERR() rather than having validation be the default. The EPSS score of 0.00467 suggests limited opportunistic exploitation, but this likely reflects that NTFS on Linux is a niche target requiring mounting a malicious image—something that happens in container escape scenarios, malware distribution, or forensic analysis pipelines, not server-to-server attacks. The real risk is supply chain: USB drives, network shares formatted by foreign systems, container images, and sandboxed filesystem processors handling untrusted NTFS data. Those environments are where a single crafted image could propagate undefined kernel state into analysis frameworks or memory forensics tools. The analytical question that should carry forward: is this pattern of returning unsanitized disk-derived values present in other functions within the NTFS driver or other Linux filesystem implementations? The MREF error-encoding pattern was borrowed from Windows NT internals where all consumers existed in a unified codebase with shared understanding—those assumptions never transferred to Linux. Search other MREF_ERR() consumers for similar validation gaps. The NTFS3 driver receives less filesystem-team attention than ext4 or xfs, and this vulnerability is likely a signal that deeper scrutiny of the driver's maintenance surface is warranted, not just this one function.

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