CVE-2026-89785: fs/ntfs3: fix out-of-bounds read of INDEX_ROOT in reparse/objid init
In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: fix out-of-bounds read of INDEXROOT in reparse/objid init
ntfsreparseinit() and ntfsobjidinit() parse the index root of the $Extend/$Reparse and $Extend/$ObjId metafiles (the INDEXROOT attributes named $R and $O). They read its type and rule fields through residentdata(), which does not check that the resident attribute is large enough to hold them.
mienumattr() accepts a resident attribute with dataoff == asize and datasize == 0. For such an attribute placed last in its MFT record, residentdata() returns a pointer to the end of the recordsize buffer, so reading root->type / root->rule reads past the allocation.
Use residentdataex(attr, sizeof(struct INDEXROOT)) and bail out when it returns NULL, as ntfssecurityinit() already does for $SDH / $SII.
The attribute is only parsed while mounting a crafted image, so this needs CAPSYSADMIN.
BUG: KASAN: slab-out-of-bounds in ntfsreparseinit (fs/ntfs3/fsntfs.c:2306) Read of size 4 at addr ffff88801219dc00 by task mount ntfsreparseinit (fs/ntfs3/fsntfs.c:2306) ntfsfillsuper (fs/ntfs3/super.c:1604) gettreebdevflags (fs/super.c:1703) vfsgettree (fs/super.c:1758) pathmount (fs/namespace.c:4131) x64sysmount (fs/namespace.c:4360)
Affected Software
Event History
Frequently Asked Questions
Who is realistically exposed to this issue?
Systems are exposed only when a crafted NTFS image is mounted and its $Extend/$Reparse or $Extend/$ObjId metadata is parsed. Exploitation requires CAP_SYS_ADMIN, so an unprivileged local user cannot trigger it without that capability.
What happens when the malformed metadata is processed?
The kernel can read past the allocation while initializing reparse-point or object-ID index data during the mount operation. The reported failure is a KASAN slab-out-of-bounds read in ntfs_reparse_init.