CVE-2026-80673: ntfs: bound the look-ahead attribute-list entry in ntfs_external_attr_find()
In the Linux kernel, the following vulnerability has been resolved:
ntfs: bound the look-ahead attribute-list entry in ntfsexternalattrfind()
When resolving an attribute lookup with a non-zero @lowestvcn, ntfsexternalattrfind() peeks at the next $ATTRIBUTELIST entry to decide whether to keep searching, but bounds that not-yet-validated entry only with "(u8 )nextalentry + 6 < alend" (which proves just bytes 0..6 are in range) and "(u8 )nextalentry + length <= alend" with an attacker-controlled, non-8-aligned length. It then reads nextalentry->lowestvcn (an le64 at offset 8) and the name at nextalentry->nameoffset, both of which can lie past alend -- the exact end of the kvmalloc'd attribute-list buffer (allocated at the on-disk attrlistsize, no rounding). A crafted on-disk $ATTRIBUTELIST whose last entry sits a few bytes before alend therefore yields a slab out-of-bounds read when the inode is read.
Validate the look-ahead entry with ntfsattrlistentryisvalid() (added in patch 1/3) before dereferencing lowestvcn and the name, so the same fixed-header, length and name bounds the main attribute-list walk uses now guard this read too.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Patch 1/3
Event History
Frequently Asked Questions
What systems are exposed to this issue?
Linux systems that read an NTFS filesystem containing a crafted on-disk $ATTRIBUTE_LIST may be exposed. The vulnerable path is reached while reading an inode and resolving an attribute lookup with a non-zero lowest_vcn.
What does an attacker need to exploit it?
An attacker needs to provide or cause the system to read a crafted NTFS filesystem with a malformed final $ATTRIBUTE_LIST entry. The malformed entry can cause reads beyond the allocated attribute-list buffer.
Is this triggered by a default configuration?
The provided information does not identify a specific default configuration. Exposure depends on the kernel reading a crafted NTFS filesystem and reaching the affected attribute lookup path.
How can I tell whether I may already be affected?
Review whether the affected system has read untrusted or attacker-controlled NTFS filesystems. The described symptom is a slab out-of-bounds read while an inode is read, but no specific log message or detection method is provided.