Linux Kernel CVE-2026-98136

Requires a crafted NTFS filesystem image whose on-disk $AttrDef data size is smaller than a single struct attr_def entry (160 bytes; the write-up uses 120 bytes), which bypasses the weak load_and_init_attrdef() check (0 < i_size <= 0x7fffffff) and is reached when a file is created, driving ntfs_attr_add → ntfs_attr_can_be_non_resident → ntfs_attr_size_bounds_check → ntfs_attr_find_in_attrdef. Exploitation is LIMITED to scenarios where an attacker can get such a volume mounted: local access plus mount capability (CAP_SYS_ADMIN) or an automount service that mounts untrusted removable media. It is not reachable over a network and does not affect systems that never mount attacker-controlled NTFS volumes; the kernel must also have the NTFS driver enabled.

Signals are consistent and point to a moderate, not urgent, priority. The CVSS 3.1 base score of 7.1 is driven by AV:L (local attack vector), AC:L, PR:L, UI:N, with C:H and A:H - i.e. a local, low-privilege out-of-bounds read (CWE-125) that can leak kernel memory or crash the system, with no integrity impact. This is NOT a remotely exploitable flaw: exploitation requires the attacker to get a crafted NTFS image mounted on the target, so network-facing exposure is zero. The EPSS score of 0.14% (3rd percentile) correctly reflects very low expected exploitation volume, and the CVE is NOT in CISA KEV and has no public exploit identified at time of analysis - all low-risk signals agree. There is no SSVC decision data provided. Net assessment: a legitimate kernel memory-safety bug worth patching through normal cycles, but the local-only vector and dependence on mounting attacker-controlled NTFS media make it a low real-world priority except in multi-user, kiosk, forensic, or USB-automount environments where untrusted filesystems are mounted. The 'C:H' rating should be read as potential kernel-memory disclosure/instability from the OOB read rather than a classic data-exfiltration path.

An attacker with local access crafts a malicious NTFS volume whose on-disk $AttrDef data size is smaller than one 160-byte attr_def entry (e.g. 120 bytes) and gets it mounted - directly, or via a desktop/USB automount service that mounts removable media. A subsequent file-creation operation drives ntfs_attr_size_bounds_check() into ntfs_attr_find_in_attrdef(), which reads ad->type past the kvzalloc allocation, leaking adjacent kernel slab memory or crashing the kernel (KASAN slab-out-of-bounds). No public exploit is identified at time of analysis; a crafted image plus trigger is required.