CVE-2026-72197 in Linux
Summary
by MITRE • 08/15/2026
In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: bound DeleteIndexEntryAllocation memmove length
In do_action()'s DeleteIndexEntryAllocation case, e->size comes from an on-disk INDEX_BUFFER entry. When e->size makes e + e->size point past hdr + hdr->used, PtrOffset(e1, Add2Ptr(hdr, used)) returns a negative ptrdiff_t that is silently cast to a quasi-infinite size_t when passed to memmove(). The memmove then walks past the destination buffer.
The sibling DeleteIndexEntryRoot case at fslog.c:3540-3543 already carries the corresponding guard:
if (PtrOffset(e1, Add2Ptr(hdr, used)) < esize || Add2Ptr(e, esize) > Add2Ptr(lrh, rec_len) || used + esize > le32_to_cpu(hdr->total)) {
goto dirty_vol; }
Apply the same shape to the allocation-path case. Also reject esize == 0: memmove(e, e, ...) is a no-op and leaves hdr->used unchanged, hiding a malformed entry from the existing check_index_header() walk.
Reproduced under UML+KASAN on mainline 8d90b09e6741 by mounting a crafted NTFS image: the unguarded memmove takes a length of 0xffffffffffffff00 and the kernel oopses in memmove+0x81/0x1a0 on the do_action+0x36a2 frame.
[[email protected]: clang-formatted the changes]
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 resides within the Linux kernel's ntfs3 filesystem driver, specifically addressing a critical buffer overflow condition during index entry deletion operations. This flaw manifests in the DeleteIndexEntryAllocation case of the do_action function where the kernel processes on-disk INDEX_BUFFER entries without proper bounds checking. The core issue stems from the e->size field which originates from untrusted on-disk data structures, creating a potential pathway for maliciously crafted NTFS images to trigger undefined behavior through improper memory manipulation operations.
The technical implementation of this vulnerability exploits a fundamental flaw in pointer arithmetic and memory copying operations within the filesystem driver's index management code. When processing index entries, the system calculates a pointer offset using PtrOffset(e1, Add2Ptr(hdr, used)) which can produce negative values when the entry extends beyond valid buffer boundaries. This negative ptrdiff_t value gets silently cast to an unsigned size_t type, resulting in an extraordinarily large memory copy operation that traverses far beyond the intended destination buffer limits. The kernel's memmove function then executes this massive operation, causing a kernel oops and system instability.
This vulnerability directly relates to CWE-121 stack-based buffer overflow and CWE-787 out-of-bounds write conditions, representing a classic example of insufficient input validation in kernel space operations. The flaw demonstrates how seemingly benign pointer arithmetic can become catastrophic when combined with improper type casting and missing boundary checks. The issue specifically affects the NTFS3 filesystem implementation where memory management operations are performed without adequate verification of buffer limits, creating a potential attack vector for privilege escalation or denial of service attacks.
The operational impact of this vulnerability extends beyond simple kernel crashes to potentially allow attackers to craft malicious NTFS images that could be mounted by unsuspecting users. When such an image is processed through the vulnerable code path, the kernel's memory management system becomes corrupted, leading to unpredictable behavior and system instability. The vulnerability can be reproduced reliably using UML environments with KASAN enabled, demonstrating that a crafted filesystem image containing malformed index entries can trigger the exact conditions described in the exploit scenario.
The mitigation strategy involves implementing the same protective bounds checking that already exists in the sibling DeleteIndexEntryRoot case within the same codebase. This requires adding explicit validation checks to ensure that pointer offsets and calculated memory sizes remain within reasonable bounds before any memmove operations are executed. The fix must also explicitly reject cases where esize equals zero, as these would result in no-op memory operations that could mask underlying data corruption issues. This approach aligns with ATT&CK technique T1068 for local privilege escalation through kernel vulnerabilities and follows defensive programming practices recommended by the Linux kernel security team.
The solution pattern established by this fix demonstrates a critical principle in kernel security development: all memory operations involving untrusted input must include comprehensive bounds checking before any data movement occurs. The implementation should ensure that calculated buffer sizes cannot exceed available memory limits, and that pointer arithmetic results remain within valid address ranges. This vulnerability highlights the importance of maintaining consistent defensive coding practices across all code paths in kernel modules, particularly when handling filesystem structures that may contain maliciously crafted data from external sources.