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.
CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
CVSS Score: 9.8
AV:N - NTFS registers ntfs_export_ops; remote nfsd/ksmbd VFS lookups on an exported crafted NTFS volume reach ntfs_lookup→ntfs_iget→ntfs_read_locked_inode→ntfs_attr_name_get without local syscall access.
AC:L - The attacker fully controls on-disk $FILE_NAME metadata (small resident value_length with large file_name_length) in a crafted image; the fix commit reproduced the slab OOB read via ntfs_lookup deterministically with no races.
PR:N - Triggering needs only read access to mounted NTFS content (e.g., authenticated or guest NFS/SMB client on an exported share) or supplying removable media later mounted by the host; no init-namespace root or CAP_SYS_ADMIN on the lookup path.
UI:N - Once a crafted NTFS volume is mounted and exported (or loop-mounted in a user namespace), normal remote lookups/opens reach the vulnerable attribute parsing without further victim clicks or cooperative actions.
S:U - The slab out-of-bounds read and potential kernel crash stay within the mounting host kernel authority; this is standard filesystem parsing exploitation, not a VM escape, IOMMU bypass, or cross-sandbox scope change.
C:H - Callers trust inflated file_name_length and ntfs_ucstonls/utf16s_to_utf8s read past the resident $FILE_NAME value in the kmalloc-1k MFT record copy, disclosing adjacent slab heap memory beyond a few bytes.
I:H - Attacker-controlled file_name_length drives kernel parsing of forged resident metadata and adjacent slab contents; per kernel CNA guidance, this memory-corruption class can be leveraged for arbitrary kernel modification or control-flow hijack beyond the immediate read.
A:H - KASAN reports slab-out-of-bounds read from the MFT record copy on lookup; reading past the resident $FILE_NAME value can oops or panic the kernel when accessing invalid adjacent memory.
| Attack Vector |
Network |
Scope |
Unchanged |
| Attack Complexity |
Low |
Confidentiality Impact |
High |
| Privileges Required |
None |
Integrity Impact |
High |
| User Interaction |
None |
Availability Impact |
High |
AV:N - NTFS registers ntfs_export_ops; remote nfsd/ksmbd VFS lookups on an exported crafted NTFS volume reach ntfs_lookup→ntfs_iget→ntfs_read_locked_inode→ntfs_attr_name_get without local syscall access.
AC:L - The attacker fully controls on-disk $FILE_NAME metadata (small resident value_length with large file_name_length) in a crafted image; the fix commit reproduced the slab OOB read via ntfs_lookup deterministically with no races.
PR:N - Triggering needs only read access to mounted NTFS content (e.g., authenticated or guest NFS/SMB client on an exported share) or supplying removable media later mounted by the host; no init-namespace root or CAP_SYS_ADMIN on the lookup path.
UI:N - Once a crafted NTFS volume is mounted and exported (or loop-mounted in a user namespace), normal remote lookups/opens reach the vulnerable attribute parsing without further victim clicks or cooperative actions.
S:U - The slab out-of-bounds read and potential kernel crash stay within the mounting host kernel authority; this is standard filesystem parsing exploitation, not a VM escape, IOMMU bypass, or cross-sandbox scope change.
C:H - Callers trust inflated file_name_length and ntfs_ucstonls/utf16s_to_utf8s read past the resident $FILE_NAME value in the kmalloc-1k MFT record copy, disclosing adjacent slab heap memory beyond a few bytes.
I:H - Attacker-controlled file_name_length drives kernel parsing of forged resident metadata and adjacent slab contents; per kernel CNA guidance, this memory-corruption class can be leveraged for arbitrary kernel modification or control-flow hijack beyond the immediate read.
A:H - KASAN reports slab-out-of-bounds read from the MFT record copy on lookup; reading past the resident $FILE_NAME value can oops or panic the kernel when accessing invalid adjacent memory.
CVSS 3.1