CVE-2026-90048: fs/ntfs3: fix slab-out-of-bounds write in ni_create_attr_list()
In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: fix slab-out-of-bounds write in nicreateattrlist()
nicreateattrlist() allocates a fixed buffer of alaligned(recordsize) (== recordsize) bytes and then walks every attribute of the primary MFT record, writing one ATTRLISTENTRY per attribute and advancing the cursor by lesize(namelen), with no check against the end of the buffer; the total size is only computed after the loop.
A minimum-size resident attribute occupies SIZEOFRESIDENT (0x18 = 24) bytes on disk, but an unnamed attribute expands to lesize(0) (0x20 = 32) bytes in the list. Because the number of attributes in a record is not bounded (mienumattr() accepts arbitrarily many equal-type, nameless minimum-size attributes), a crafted record packed with such attributes produces a list larger than recordsize and overflows the heap buffer.
This is reachable from a crafted, loop-mounted NTFS image: opening the file and adding an attribute (e.g. via setxattr) drives ntfssetea() -> niinsertresident() -> niinsertattr() -> niinsattrext() -> nicreateattrlist().
BUG: KASAN: slab-out-of-bounds in nicreateattrlist+0xc48/0x1058 Write of size 4 at addr ffff000008984c00 by task setfattr/345 nicreateattrlist+0xc48/0x1058 niinsattrext+0x510/0x7c0 niinsertattr+0x3f8/0x70c niinsertresident+0xc8/0x3b0 ntfssetea+0x66c/0xd28 ntfssetxattr+0x4d8/0x5b0 arm64syssetxattr+0xa4/0x124 Allocated by task 345: nicreateattrlist+0x188/0x1058 The buggy address belongs to the cache kmalloc-1k of size 1024 (the write lands at object+1024).
Size the buffer from the actual attributes instead of assuming a single recordsize is always enough.
Affected Software
Event History
Frequently Asked Questions
Who is realistically exposed to this issue?
Systems that loop-mount a crafted NTFS image are exposed when a file on that image is opened and an attribute is added. This can occur through an extended-attribute operation such as setxattr.
What does an attacker need to do to trigger the overflow?
The attacker needs a crafted NTFS record containing arbitrarily many equal-type, unnamed minimum-size resident attributes. The crafted image must be loop-mounted, and an operation that adds an attribute must reach the NTFS extended-attribute insertion path.
Is merely mounting or opening the NTFS image sufficient?
The described reachable path requires opening a file and adding an attribute after the crafted image is loop-mounted. The supplied data does not state that mounting alone triggers the issue.