CVE-2026-98136 in Linux
Summary
by MITRE • 09/25/2026
In the Linux kernel, the following vulnerability has been resolved:
ntfs: bound $AttrDef table walk to the loaded table size
ntfs_attr_find_in_attrdef() 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->attrdef_size && ad->type; ++ad)
struct attr_def is 160 bytes; the guard reads ad->type at offset 128 and the loop body reads further fields. vol->attrdef is kvzalloc(i_size), where i_size is the on-disk $AttrDef data size, checked in load_and_init_attrdef() only as 0 < i_size <= 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 ntfs_attr_size_bounds_check() and reads out of bounds:
BUG: KASAN: slab-out-of-bounds in ntfs_attr_find_in_attrdef+0x66/0xa0 Read of size 4 at addr ffff888005833280 by task init/1 ntfs_attr_find_in_attrdef ntfs_attr_size_bounds_check ntfs_attr_can_be_non_resident ntfs_attr_add
Require the whole entry to lie within attrdef_size in the loop guard, and reject at mount a $AttrDef too small to hold one attr_def entry.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/25/2026
The Linux kernel's NTFS filesystem driver contains a critical out-of-bounds read vulnerability located within the ntfs_attr_find_in_attrdef function. This flaw arises from an insufficient boundary check when iterating through the in-memory attribute definition table, known as $AttrDef. The loop condition currently verifies that the starting address of each entry remains within the allocated memory region defined by vol->attrdef_size. However, it fails to account for the total size of the structure being accessed during iteration. Since the struct attr_def is 160 bytes in length and the guard only checks the initial offset up to byte 128 before reading ad->type, subsequent accesses within the loop body can easily exceed the allocated buffer if the table size is marginal or malformed.
The root cause lies in the mismatch between the on-disk data validation and the runtime memory access patterns. The volume's $AttrDef data size is validated during initialization via load_and_init_attrdef to ensure it falls within a broad range of greater than zero and less than or equal to 0x7fffffff bytes. This check does not guarantee that the table contains at least one complete attribute definition entry, which requires 160 bytes. Consequently, if an NTFS volume is formatted with an $AttrDef section smaller than this threshold, such as exactly 120 bytes, the kernel will allocate a buffer of insufficient size. When ntfs_attr_size_bounds_check triggers a file creation operation, it invokes ntfs_attr_can_be_non_resident and subsequently calls ntfs_attr_find_in_attrdef. The function then attempts to read fields from an attr_def structure that extends beyond the allocated memory region.
This vulnerability results in a slab-out-of-bounds read error as detected by Kernel Address Sanitizer (KASAN). Specifically, the kernel reads four bytes at an address past the end of the kvzalloc allocation. While this specific instance manifests as a read operation rather than a write, it constitutes a significant security risk due to information disclosure potential and system instability. The out-of-bounds access can leak sensitive kernel memory contents or cause unpredictable behavior depending on what data resides in the adjacent slab cache regions. In severe cases, such memory corruption issues can lead to kernel panics or denial of service conditions for systems relying on NTFS filesystem support.
From a classification perspective, this vulnerability aligns with CWE-125: Out-of-bounds Read and CWE-787: Out-of-bounds Write in the context of improper boundary checks leading to memory safety violations. It also relates to CWE-20: Improper Input Validation regarding the failure to validate that input data meets minimum structural requirements before processing. In terms of attack vectors, this could be leveraged by an attacker with local access who can mount a maliciously crafted NTFS volume or manipulate filesystem metadata to trigger the out-of-bounds read during standard file system operations like creating new files.
The mitigation involves modifying the loop condition in ntfs_attr_find_in_attrdef to ensure that both the start and end of each attribute definition entry remain within the bounds of vol->attrdef_size. Additionally, the initialization logic must be updated to reject any $AttrDef table that is too small to hold at least one complete attr_def structure during mount time. This prevents the kernel from operating on malformed or truncated metadata structures that do not conform to expected NTFS specifications. System administrators should apply available kernel patches that address this specific boundary check failure and ensure that mounted volumes are verified for structural integrity before allowing standard file operations.