Linux Kernel up to 7.1.4 NTFS ntfs_attr_find/ntfs_external_attr_find out-of-bounds

Summaryinfo

A vulnerability marked as problematic has been reported in Linux Kernel up to 7.1.4. Affected is the function ntfs_attr_find/ntfs_external_attr_find of the component NTFS. The manipulation leads to out-of-bounds. This vulnerability is listed as CVE-2026-72209. The attack must be carried out locally. There is no available exploit.

Detailsinfo

A vulnerability was found in Linux Kernel up to 7.1.4. It has been rated as problematic. This issue affects the function ntfs_attr_find/ntfs_external_attr_find of the component NTFS. The manipulation with an unknown input leads to a out-of-bounds vulnerability. Using CWE to declare the problem leads to CWE-125. The product reads data past the end, or before the beginning, of the intended buffer. Impacted is confidentiality, integrity, and availability. The summary by CVE is:

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.

The advisory is shared at git.kernel.org. The identification of this vulnerability is CVE-2026-72209 since 08/09/2026. The exploitation is known to be easy. An attack has to be approached locally. Additional levels of successful authentication are necessary for exploitation. It demands that the victim is doing some kind of user interaction. Technical details are known, but no exploit is available.

Upgrading to version 7.1.5 or 7.2-rc1 eliminates this vulnerability. Applying the patch e4c36dfac57a7261e9aeb0f3a7f30944a8aefb56/d5803e3345dae9c6470bb61869885236276b9a35 is able to eliminate this problem.

If you want to get the best quality for vulnerability data then you always have to consider VulDB.

Productinfo

Type

• Operating System

Vendor

• Linux

Name

• Kernel

Version

• 7.1.0
• 7.1.1
• 7.1.2
• 7.1.3
• 7.1.4

License

• open-source

Website

• Vendor: https://www.kernel.org/

CPE 2.3info

• 🔒
• 🔒
• 🔒

CPE 2.2info

• 🔒
• 🔒
• 🔒

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

If you want to get the best quality for vulnerability data then you always have to consider VulDB.

Discussion