In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: validate ef->size covers the record's name and value
When an EA record has a non-zero ef->size, ntfs_read_ea() only checks
that the record fits in the remaining buffer (ea_size > bytes), not that
ef->size is large enough to hold the record's own name_len + 1 + elength.
A crafted image can pass validation with, e.g., ef->size = 24 but
elength = 0xffff. ntfs_get_ea() then trusts elength and copies it out of
the undersized record, reading past the kmalloc(info->size) allocation
and leaking heap memory to userspace via getxattr():
BUG: KASAN: slab-out-of-bounds in ntfs_get_ea (fs/ntfs3/xattr.c:302)
Read of size 65535 at addr ffff888100794550 by task exploit
__asan_memcpy (mm/kasan/shadow.c:105)
ntfs_get_ea (fs/ntfs3/xattr.c:302)
ntfs_getxattr (fs/ntfs3/xattr.c:848)
__vfs_getxattr (fs/xattr.c:441)
vfs_getxattr (fs/xattr.c:474)
do_getxattr (fs/xattr.c:800)
path_getxattrat (fs/xattr.c:868)
do_syscall_64 (arch/x86/entry/syscall_64.c:94)
The buggy address is located 80 bytes inside of
allocated 84-byte region in cache kmalloc-96
Compute the size the record needs and require ef->size to cover it.
CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H
CVSS Score: 9.1
AV:N - ntfs3 registers export_operations and an empty-prefix xattr handler, so ksmbd SMB2 QUERY_INFO FILE_FULL_EA and nfsd GETXATTR reach vfs_getxattr→ntfs_getxattr→ntfs_get_ea on an exported NTFS volume; a crafted EA named user.* is listed and returned over the network on NAS/hybrid SMB/NFS servers.
AC:L - The attacker fully controls on-disk EA_FULL fields; ef->size=24 with elength=0xffff passes ntfs_read_ea() and makes ntfs_get_ea() memcpy 65535 bytes past the kmalloc(info->size) object deterministically, with no race or attacker-uncontrollable layout.
PR:N - The leak needs only read access to a file carrying the crafted EA: a ksmbd guest/anonymous client with FILE_READ_EA, an NFSv4 AUTH_SYS/guest GETXATTR, or automount of attacker media, with no local account or CAP_SYS_ADMIN on the host.
UI:N - After the NTFS volume is mounted and exported—the normal state for NAS, dual-boot, and automounted removable NTFS—the attacker issues SMB QUERY_INFO, NFS GETXATTR, or getxattr(2) themselves; no further victim clicks, prompts, or confirmations are required.
S:U - The slab over-read and heap leak occur in the host kernel ntfs3 xattr path under a single security authority; this is standard filesystem exploitation, not a VM escape, IOMMU/DMA bypass, or other cross-boundary breakout.
C:H - ntfs_get_ea() copies attacker-chosen elength (up to 65535) bytes from past the kmalloc(info->size) EA buffer into the getxattr output that VFS, ksmbd, and nfsd return to the caller; a ~64KiB kernel-heap leak to userspace or a remote SMB/NFS client is Confidentiality High.
I:N - The destination is sized from the probed elength (ksmbd/nfsd) or the caller-supplied size with an explicit len>size ERANGE check, so this is a source over-read into a bounds-checked xattr buffer, not an out-of-bounds write, UAF, or control-flow hijack primitive.
A:H - KASAN reports a 65535-byte slab-out-of-bounds read in ntfs_get_ea from an 84-byte kmalloc-96 object; that unbounded heap over-read can fault unmapped adjacent slab pages and oops or panic the kernel, which is Availability High.
| Attack Vector |
Network |
Scope |
Unchanged |
| Attack Complexity |
Low |
Confidentiality Impact |
High |
| Privileges Required |
None |
Integrity Impact |
None |
| User Interaction |
None |
Availability Impact |
High |
AV:N - ntfs3 registers export_operations and an empty-prefix xattr handler, so ksmbd SMB2 QUERY_INFO FILE_FULL_EA and nfsd GETXATTR reach vfs_getxattr→ntfs_getxattr→ntfs_get_ea on an exported NTFS volume; a crafted EA named user.* is listed and returned over the network on NAS/hybrid SMB/NFS servers.
AC:L - The attacker fully controls on-disk EA_FULL fields; ef->size=24 with elength=0xffff passes ntfs_read_ea() and makes ntfs_get_ea() memcpy 65535 bytes past the kmalloc(info->size) object deterministically, with no race or attacker-uncontrollable layout.
PR:N - The leak needs only read access to a file carrying the crafted EA: a ksmbd guest/anonymous client with FILE_READ_EA, an NFSv4 AUTH_SYS/guest GETXATTR, or automount of attacker media, with no local account or CAP_SYS_ADMIN on the host.
UI:N - After the NTFS volume is mounted and exported—the normal state for NAS, dual-boot, and automounted removable NTFS—the attacker issues SMB QUERY_INFO, NFS GETXATTR, or getxattr(2) themselves; no further victim clicks, prompts, or confirmations are required.
S:U - The slab over-read and heap leak occur in the host kernel ntfs3 xattr path under a single security authority; this is standard filesystem exploitation, not a VM escape, IOMMU/DMA bypass, or other cross-boundary breakout.
C:H - ntfs_get_ea() copies attacker-chosen elength (up to 65535) bytes from past the kmalloc(info->size) EA buffer into the getxattr output that VFS, ksmbd, and nfsd return to the caller; a ~64KiB kernel-heap leak to userspace or a remote SMB/NFS client is Confidentiality High.
I:N - The destination is sized from the probed elength (ksmbd/nfsd) or the caller-supplied size with an explicit len>size ERANGE check, so this is a source over-read into a bounds-checked xattr buffer, not an out-of-bounds write, UAF, or control-flow hijack primitive.
A:H - KASAN reports a 65535-byte slab-out-of-bounds read in ntfs_get_ea from an 84-byte kmalloc-96 object; that unbounded heap over-read can fault unmapped adjacent slab pages and oops or panic the kernel, which is Availability High.
CVSS 3.1