CVE-2026-72209 in Linux
Summary
by MITRE • 08/15/2026
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.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/15/2026
The vulnerability in question affects the ntfs driver within the Linux kernel, specifically targeting how attribute values are validated during filesystem lookup operations. This issue stems from insufficient validation of attribute data structures that can lead to out-of-bounds memory access when processing crafted NTFS images. The problem manifests primarily through ntfs_attr_find() and ntfs_external_attr_find() functions which perform checks on resident attribute values but fail to adequately validate variable-length fields within these structures. The core flaw occurs when a maliciously constructed filesystem image sets a small resident value_length field while maintaining a large file_name_length field, creating a scenario where subsequent code paths trust the larger file_name_length value and attempt to read beyond the actual bounds of the resident attribute data.
The technical exploitation of this vulnerability involves a slab-out-of-bounds read condition that was observed under KASAN memory debugging framework, specifically manifesting as an access to kmalloc-1k MFT record copy. The call stack demonstrates how this vulnerability propagates through multiple kernel functions including ntfs_lookup(), ntfs_iget(), ntfs_read_locked_inode(), ntfs_attr_name_get(), ntfs_ucstonls(), and utf16s_to_utf8s(), indicating the widespread impact across filesystem operation pathways. This validation gap represents a classic case of insufficient input sanitization where attacker-controlled metadata can bypass normal bounds checking mechanisms, effectively allowing arbitrary memory reads beyond allocated buffer boundaries.
The operational impact of this vulnerability extends beyond simple memory corruption to potentially enable privilege escalation or denial-of-service conditions within kernel space operations. The fix implements a shared attribute value validator that enforces comprehensive validation before any lookup path returns an attribute, including handling the AT_UNUSED enumeration case where direct attribute inspection occurs. This approach addresses multiple validation aspects simultaneously: resident value bounds checking, minimum resident value size requirements, variable-length FILE_NAME field validation, and non-resident mapping-pairs metadata verification that was previously handled separately in both lookup code paths.
The mitigation strategy also preserves proper resident value matching semantics in external attribute lookup operations by ensuring that the actual value length comparison is maintained rather than overwriting with type-specific minimum lengths. The implementation addresses a specific issue where ntfs_attrlist_entry_add() previously compared resident attributes using non-resident union members after successful resident matches, which could cause false mismatches even when identical bytes were present. Additionally, the fix explicitly rejects non-resident FILE_NAME records since the filesystem format specification requires FILE_NAME attributes to remain resident, and all callers expect resident data structures for proper operation.
This vulnerability aligns with CWE-129 Input Validation and CWE-787 Out-of-bounds Write categories, representing a memory safety issue that can be exploited through crafted input data. From an ATT&CK perspective, this corresponds to techniques involving privilege escalation through kernel vulnerabilities and code execution in kernel space contexts. The fix demonstrates proper defensive programming practices by implementing centralized validation logic rather than scattered checks, reducing the potential for similar issues in related code paths and improving overall filesystem driver robustness against malformed input data structures.