CVE-2026-72191 in Linux
Summary
by MITRE • 08/15/2026
In the Linux kernel, the following vulnerability has been resolved:
ntfs3: validate split-point offset in indx_insert_into_buffer
indx_insert_into_buffer() computes
used = used1 - to_copy - sp_size; memmove(de_t, Add2Ptr(sp, sp_size), used - le32_to_cpu(hdr1->de_off));
where sp and sp_size come from hdr_find_split(). hdr_find_split() walks entries by le16_to_cpu(e->size) without validating that each step stays within hdr->used or that the size field is at least sizeof(struct NTFS_DE). index_hdr_check(), the on-load gatekeeper, only validates header-level fields (used, total, de_off) and does not walk per-entry sizes.
A crafted NTFS image whose leaf INDEX_HDR reports used == total but contains one interior NTFS_DE with size = 0xFFF0 therefore passes validation, descends to indx_insert_into_buffer() through the ntfs_create() -> indx_insert_entry() path, and makes hdr_find_split() return an sp whose sp_size (0xFFF0) greatly exceeds the remaining bytes in the buffer. The u32 subtraction underflows and the memmove count becomes a near-4-GiB value, producing an out-of-bounds kernel write that corrupts adjacent allocations and panics the kernel.
Reproduced on 7.0.0-rc7 with UML + KASAN via a crafted image and a single 'touch' inside the mounted directory; crash site resolves to fs/ntfs3/index.c at the memmove. Trigger requires only local mount of an attacker-supplied filesystem image (USB, loopback, or removable media auto-mount).
Reject the split whenever the chosen sp plus its declared size already extends past hdr1->used. This is the minimal fix; it preserves the existing hdr_find_split() contract and relies on the same out: cleanup path as the pre-existing error returns.
A prior OOB read in the very same indx_insert_into_buffer() memmove was fixed in commit b8c44949044e ("fs/ntfs3: Fix OOB read in indx_insert_into_buffer") by tightening hdr_find_e(), but that fix does not cover the split-point size field path addressed here: sp is returned by hdr_find_split(), not hdr_find_e(), and the underflow is driven by sp->size rather than hdr->used exceeding hdr->total.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/15/2026
The vulnerability described in this CVE affects the Linux kernel's ntfs3 filesystem driver, specifically within the indx_insert_into_buffer() function where a critical validation flaw allows for out-of-bounds memory operations. This issue stems from inadequate bounds checking during index entry insertion processes in NTFS filesystems, creating a potential pathway for kernel exploitation through crafted filesystem images.
The technical root cause lies in how hdr_find_split() function processes directory entries without proper validation of entry size fields or buffer boundaries. The function iterates through entries using le16_to_cpu(e->size) without ensuring that each step remains within the header's used space or that the size field contains a valid minimum structure size of sizeof(struct NTFS_DE). While index_hdr_check() performs header-level validation on fields like used, total, and de_off, it does not validate individual entry sizes, creating a gap in the security boundary.
This vulnerability manifests when a crafted NTFS image presents an interior directory entry with a size field set to 0xFFF0 while maintaining the header's used == total condition. The valid header passes initial validation but allows hdr_find_split() to return a split point whose declared size exceeds available buffer space, causing a u32 underflow in the memory operation calculation. The resulting memmove function receives an almost 4-gigabyte count parameter, leading to kernel memory corruption and system panic.
The operational impact is significant as this vulnerability requires only local access to mount an attacker-controlled filesystem image, making it exploitable through removable media auto-mount mechanisms or loopback devices. The attack vector is particularly dangerous because it can be triggered with a simple touch command within the mounted directory, demonstrating how a single user-level operation can escalate to kernel-level privilege escalation.
The fix implements a straightforward validation check that rejects any split point calculation where the chosen split position plus its declared size would exceed the header's used space. This minimal change preserves existing function contracts and leverages the established error handling cleanup paths already present in the codebase. The solution addresses the specific underflow condition driven by split-point size fields rather than the previously fixed out-of-bounds read issue that affected the hdr_find_e() function path.
This vulnerability aligns with CWE-129 Input Validation and CWE-787 Out-of-bounds Write, representing a classic case of insufficient boundary checking in kernel memory operations. From an ATT&CK perspective, this represents a privilege escalation technique through filesystem manipulation, potentially enabling attackers to gain kernel-level privileges by exploiting memory corruption vulnerabilities in the filesystem layer. The fix demonstrates proper defensive programming practices by implementing immediate bounds validation before proceeding with memory operations, preventing the arithmetic underflow that leads to the exploitable condition.
The vulnerability highlights critical security considerations in filesystem drivers where internal consistency checks must validate all data structures before processing, particularly in contexts where user-supplied data can influence kernel memory operations. The fact that this issue exists in a widely-used filesystem driver underscores the importance of comprehensive validation across all code paths, especially those involving complex data structure manipulation and memory movement operations.