Vulnerability in Linux
CVE-2026-72209
In the Linux kernel, the following vulnerability has been resolved: ntfs: validate attribute values on lookup ntfs_attr_find() and ntfs_external_attr_find() check that generic resident attribute values fit in their attribute records and that fixed-size resident values are large enough. For variable-length resident formats, however, the fixed part is not enough: embedded length fields can still point callers past the resident value. A crafted image can set a small resident $FILE_NAME value_length while leaving file_name_length large. Callers then trust file_name_length and read past the resident value when converting or comparing the name. This was reproduced with a crafted image under KASAN as a slab-out-of-bounds read from the kmalloc-1k MFT record copy. The stack included ntfs_lookup(), ntfs_iget(), ntfs_read_locked_inode(), ntfs_attr_name_get(), ntfs_ucstonls(), and utf16s_to_utf8s(). Add a shared attribute value validator and use it before a lookup path can return an attribute, including the AT_UNUSED enumeration case where callers inspect returned attributes directly. The helper validates resident value bounds, minimum resident value sizes, variable-length $FILE_NAME fields, and non-resident mapping-pairs metadata that was previously checked separately in both lookup paths. This also preserves the intended resident @val matching semantics in the external attribute lookup path. The old duplicated validation block overwrote the actual resident value length with the type-specific minimum length before comparing @val, so variable-length resident values could fail to match even when the bytes were identical. Keep the comparison on the actual value length, and make ntfs_attrlist_entry_add() compare resident attributes with lowest_vcn zero instead of reading the non-resident union member after a successful resident match. Reject non-resident $FILE_NAME records too: the format requires $FILE_NAME to be resident and callers treat returned records as resident.
Published · last modified .
CVSS v3 metric
CVSS v3 base score 9.8 (Critical). Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H.
EPSS exploit prediction
EPSS: 0.006 (44.0th percentile), scored .
Very low probability of exploitation in the next 30 days; routine patching cadence is appropriate. 44th percentile — 44.0% of CVEs in the catalogue have a lower EPSS than this one. How to read EPSS.
EPSS over last 30 days · oldest: 0.005 · newest: 0.006 · change: +0.000
Affected products
- Linux — versions 7.2-rc1, 7.2, 6ceb4cc81ef3409ff79dcb959771f9110787397a
References
Frequently asked questions
- What is CVE-2026-72209?
- CVE-2026-72209 is a critical-severity vulnerability in Linux. CVSS score: 9.8/10. Published 2026-08-15.
- How severe is CVE-2026-72209?
- Critical severity. CVSS v3 base score is 9.8 out of 10.