CVE-2026-98136: ntfs: bound $AttrDef table walk to the loaded table size
In the Linux kernel, the following vulnerability has been resolved:
ntfs: bound $AttrDef table walk to the loaded table size
ntfsattrfindinattrdef() walks the in-memory $AttrDef table, but the loop condition bounds only the start of each entry, not the whole entry:
for (ad = vol->attrdef; (u8 )ad - (u8 )vol->attrdef < vol->attrdefsize && ad->type; ++ad)
struct attrdef is 160 bytes; the guard reads ad->type at offset 128 and the loop body reads further fields. vol->attrdef is kvzalloc(isize), where isize is the on-disk $AttrDef data size, checked in loadandinitattrdef() only as 0 < isize <= 0x7fffffff. A volume whose $AttrDef data size is smaller than one entry (e.g. 120 bytes) makes the read of ad->type run past the allocation. Creating a file reaches this through ntfsattrsizeboundscheck() and reads out of bounds:
BUG: KASAN: slab-out-of-bounds in ntfsattrfindinattrdef+0x66/0xa0 Read of size 4 at addr ffff888005833280 by task init/1 ntfsattrfindinattrdef ntfsattrsizeboundscheck ntfsattrcanbenonresident ntfsattradd
Require the whole entry to lie within attrdefsize in the loop guard, and reject at mount a $AttrDef too small to hold one attrdef entry.
Affected Software
Event History
Frequently Asked Questions
What input is required to trigger the out-of-bounds read?
The mounted NTFS volume must contain $AttrDef data smaller than a full 160-byte attr_def entry. The description gives a 120-byte $AttrDef as an example that causes ad->type to be read beyond the allocated buffer.
What operation can reach the vulnerable code path?
Creating a file can reach the affected lookup through ntfs_attr_size_bounds_check(), ntfs_attr_can_be_non_resident(), and ntfs_attr_add.
How does the resolved behavior handle malformed $AttrDef data?
The fix requires a complete attr_def entry to fit within attrdef_size during the table walk. It also rejects $AttrDef data at mount time when it is too small to hold one attr_def entry.