CVE-2026-89779
CriticalCVSS 9.1Exploitation Probability (EPSS)
Low risk11th percentile - higher than 11% of all known CVEs
Summary
In the Linux kernel, fs/ntfs3's ntfs_read_ea() does not verify that the EA record's ef->size is large enough to hold the record's name and value. A crafted NTFS image can set a small ef->size with a large elength, causing an out-of-bounds read past the allocated buffer and leaking kernel heap memory to userspace via getxattr().
Risk Assessment
A local attacker can mount a crafted NTFS image and read kernel heap memory through a getxattr() call, potentially disclosing sensitive data or defeating protections such as ASLR.
Recommendation
Update the Linux kernel to a version containing the fix that validates ef->size covers the record's name and value. Until then, avoid mounting untrusted NTFS images.
Other vulnerabilities in Linux kernel (fs/ntfs3)
See all- CVE-2026-89782High
A vulnerability was found in the Linux kernel's fs/ntfs3 module due to missing validation of restart table growth during $LogFile replay. When mounting a crafted NTFS image, an entry count exceeding U16_MAX is truncated, causing allocation of a table smaller than required and an out-of-bounds access.
- CVE-2026-89617High
In the Linux kernel, the fs/ntfs3 driver does not validate the dirty page table during log replay. A crafted DIR_PAGE_ENTRY with an invalid lcns_follow field lets the v0->v1 conversion and later replay passes run off the entry.
- CVE-2026-89616High
In the Linux kernel, ni_read_frame() in fs/ntfs3 trusts decompress_lznt()'s return value, which may be smaller than the frame size. Unwritten bytes remain in the vmapped pages and are returned to userspace, disclosing uninitialized kernel memory.
- CVE-2026-89615High
In the Linux kernel, the copy_lcns and redo shorten loops in fs/ntfs3 index page_lcns[] based on the log record's lcns_follow, which is not checked against the target entry. A crafted record can overflow page_lcns[] of an otherwise valid entry.
- CVE-2026-45864Medium
In the Linux kernel's NTFS3 filesystem, an infinite loop vulnerability was found when processing the range [valid : pos). If the valid value cannot be read correctly and remains the same, a process hang may occur, as reported by syzbot. A check was added to detect unchanged valid values and return -EINVAL.
- CVE-2025-71311High
In the Linux kernel, the NTFS3 filesystem has a vulnerability involving the use of uninitialized folios. Newly allocated folios are not marked as uptodate, and the ni_read_frame() function is skipped when the caller expects the frame to be completely overwritten, leaving part of the memory uninitialized.
Original NVD description (English source)
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.