CRITICAL
ntfs3 EARecord OOB
CVE-2026-89779
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H
KernelScan AI6.0MEDIUM
01Description
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.
02KernelScan AI Analysis
Risk summary
A crafted NTFS filesystem image can trick the ntfs3 extended-attribute parser into reading far past its allocated buffer, leaking kernel heap memory to userspace via getxattr(). The bug requires mounting a malicious image, which needs real root (CAP_SYS_ADMIN in the init namespace), so unprivileged users cannot trigger it directly. Products that accept removable media or allow root to mount arbitrary filesystems are at risk of information disclosure and potential kernel instability.
Vulnerability analysis
When the ntfs3 driver parses extended-attribute records from a mounted image, it validates that each record fits within the remaining buffer but does not verify that the record's declared size is large enough to contain its own name and value fields. A crafted image can declare a small record size alongside a large value length, so when userspace later requests that attribute via getxattr, the driver trusts the oversized length and copies data well beyond the heap allocation, leaking kernel memory to userspace. The fix computes the minimum size each record needs (its name length plus value length) and rejects any record whose declared size does not cover it. The vulnerable path is reached only by mounting a crafted NTFS filesystem, which requires real root privileges — an unprivileged user cannot mount ntfs3 inside a user namespace, so the realistic attacker is someone with physical access to a removable-media port or an account that can run mount.
Lifecycle
03Fix Versions
| Branch | Introduced | Fixed in | Patch commit |
|---|---|---|---|
| 5.15 | 5.15.121 | 5.15.221 | b27e68ad818a |
| 6.18 | — | 6.18.52 | aab1880058ac |
| mainline | — | 7.3-rc1 | c22f91d82cb9 |
| 6.12 | — | 6.12.110 | 077df8464cf2 |
| 6.1 | 6.1.40 | 6.1.188 | 28a924c7e67e |
| 7.2 | — | 7.2.6 | c8a109c9e23a |
| 6.6 | — | 6.6.157 | d585ed083089 |