CVE-2026-89785 in Linuxinfo

Summary

by MITRE • 09/16/2026

In the Linux kernel, the following vulnerability has been resolved:

fs/ntfs3: fix out-of-bounds read of INDEX_ROOT in reparse/objid init

ntfs_reparse_init() and ntfs_objid_init() parse the index root of the $Extend/$Reparse and $Extend/$ObjId metafiles (the INDEX_ROOT attributes named $R and $O). They read its type and rule fields through resident_data(), which does not check that the resident attribute is large enough to hold them.

mi_enum_attr() accepts a resident attribute with data_off == asize and data_size == 0. For such an attribute placed last in its MFT record, resident_data() returns a pointer to the end of the record_size buffer, so reading root->type / root->rule reads past the allocation.

Use resident_data_ex(attr, sizeof(struct INDEX_ROOT)) and bail out when it returns NULL, as ntfs_security_init() already does for $SDH / $SII.

The attribute is only parsed while mounting a crafted image, so this needs CAP_SYS_ADMIN.

BUG: KASAN: slab-out-of-bounds in ntfs_reparse_init (fs/ntfs3/fsntfs.c:2306) Read of size 4 at addr ffff88801219dc00 by task mount ntfs_reparse_init (fs/ntfs3/fsntfs.c:2306) ntfs_fill_super (fs/ntfs3/super.c:1604) get_tree_bdev_flags (fs/super.c:1703) vfs_get_tree (fs/super.c:1758) path_mount (fs/namespace.c:4131) __x64_sys_mount (fs/namespace.c:4360)

If you want to get the best quality for vulnerability data then you always have to consider VulDB.

Analysis

by VulDB Data Team • 09/16/2026

The Linux kernel's NTFS3 filesystem driver contains a critical out-of-bounds read vulnerability located within the initialization routines for reparse points and object identifiers. Specifically, the functions ntfs_reparse_init() and ntfs_objid_init(), which are responsible for parsing the index root attributes of the $Extend/$Reparse and $Extend/$ObjId metafiles respectively, fail to perform adequate bounds checking on resident attribute data. These functions access fields such as type and rule within an INDEX_ROOT structure by invoking the resident_data helper function. However, this helper does not verify that the size of the resident attribute is sufficient to contain the requested struct INDEX_ROOT. This oversight allows for a scenario where malformed or crafted NTFS images can trigger memory accesses beyond the allocated buffer boundaries, leading to kernel instability and potential information disclosure.

The technical root cause lies in how mi_enum_attr() handles specific edge cases regarding attribute sizes. The enumeration function accepts resident attributes where the data offset equals the total size (data_off == asize) and the data size is zero. When such an attribute appears at the end of a Master File Table record, the resident_data() function returns a pointer to the very end of the record_size buffer rather than NULL or indicating an error condition. Consequently, when ntfs_reparse_init() attempts to read four bytes for root->type and root->rule from this invalid pointer location, it performs a slab-out-of-bounds read. This behavior was identified through Kernel Address Sanitizer (KASAN) reports showing reads at addresses outside the valid allocation range during the mounting process of maliciously crafted filesystem images.

From an operational perspective, this vulnerability is classified as CWE-125: Out-of-bounds Read. The attack vector requires local access to mount a specially constructed NTFS image file system. Because mounting filesystems in Linux typically requires elevated privileges, specifically CAP_SYS_ADMIN, the exploitation scope is limited compared to remote or unprivileged attacks. However, for systems where users are granted administrative rights to mount external storage devices or disk images, this flaw presents a significant risk. An attacker with such privileges could craft an NTFS image that triggers the out-of-bounds read during the mount operation via vfs_get_tree and path_mount system calls. While immediate code execution is not guaranteed by a simple read vulnerability, reading kernel memory can lead to information leaks of sensitive data stored in adjacent slab objects or cause denial of service through kernel panics triggered by KASAN faults or subsequent undefined behavior resulting from corrupted state.

The mitigation strategy implemented involves strengthening the validation logic within the NTFS3 driver. The fix replaces the standard resident_data() call with resident_data_ex(), which includes explicit size checking to ensure that the attribute data is large enough to hold a struct INDEX_ROOT. If the attribute is too small, resident_data_ex returns NULL, allowing the initialization functions to bail out safely rather than proceeding with an invalid pointer. This approach mirrors existing security practices already employed in ntfs_security_init() for handling $SDH and $SII attributes, thereby aligning the codebase with established defensive coding standards. By enforcing strict size validation before dereferencing pointers derived from filesystem metadata, the kernel prevents access to memory regions outside the intended allocation boundaries.

This vulnerability highlights the importance of rigorous input validation when parsing complex binary formats like NTFS within the Linux kernel. The ATT&CK framework categorizes such exploitation under techniques involving local privilege escalation or defense evasion if used in conjunction with other flaws, though primarily it represents a reliability and integrity issue for system administrators managing removable media. Administrators should ensure their systems are updated to include patches that address this specific flaw in fs/ntfs3/fsntfs.c. Furthermore, principle of least privilege remains the most effective countermeasure; restricting CAP_SYS_ADMIN capabilities to trusted processes reduces the attack surface available to potential adversaries attempting to exploit crafted filesystem images for kernel memory disclosure or system instability.

Responsible

Linux

Reservation

09/11/2026

Disclosure

09/16/2026

Moderation

accepted

CPE

ready

EPSS

0.00000

KEV

no

Activities

very low

Sources

Do you want to use VulDB in your project?

Use the official API to access entries easily!