Get a Demo

Let's Patch It!

Book a short call with one our specialists, we'll walk you through how Endor Patches work, and ask you a few questions about your environment (like your primary programming languages and repository management). We'll also send you an email right after you fill out the form, feel free to reply with any questions you have in advance!

CVE

DEBIAN-CVE-2026-72191

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_...
Back to all
CVE

DEBIAN-CVE-2026-72191

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_...

In the Linux kernel, the following vulnerability has been resolved:  ntfs3: validate split-point offset in indxinsertintobuffer  indxinsertintobuffer() computes      used = used1 - tocopy - spsize;     memmove(det, Add2Ptr(sp, spsize), used - le32tocpu(hdr1->deoff));  where sp and spsize come from hdrfindsplit().  hdrfindsplit() walks entries by le16tocpu(e->size) without validating that each step stays within hdr->used or that the size field is at least sizeof(struct NTFSDE).  indexhdrcheck(), the on-load gatekeeper, only validates header-level fields (used, total, deoff) and does not walk per-entry sizes.  A crafted NTFS image whose leaf INDEXHDR reports used == total but contains one interior NTFSDE with size = 0xFFF0 therefore passes validation, descends to indxinsertintobuffer() through the ntfscreate() -> indxinsertentry() path, and makes hdrfindsplit() return an sp whose spsize (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 hdrfindsplit() contract and relies on the same out: cleanup path as the pre-existing error returns.  A prior OOB read in the very same indxinsertintobuffer() memmove was fixed in commit b8c44949044e ("fs/ntfs3: Fix OOB read in indxinsertintobuffer") by tightening hdrfinde(), but that fix does not cover the split-point size field path addressed here: sp is returned by hdrfindsplit(), not hdrfind_e(), and the underflow is driven by sp->size rather than hdr->used exceeding hdr->total.

Package Versions Affected

Package Version
patch Availability
No items found.

Automatically patch vulnerabilities without upgrading

Fix Without Upgrading
Detect compatible fix
Apply safe remediation
Fix with a single pull request

CVSS Version

Severity
Base Score
CVSS Version
Score Vector
C
H
U
-
C
H
U
0
-
3.1
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
C
H
U
-

Related Resources

No items found.

References

https://security-tracker.debian.org/tracker/CVE-2026-72191

Severity

9.8

CVSS Score
0
10

Basic Information

Base CVSS
9.8
EPSS Probability
0%
EPSS Percentile
0%
Introduced Version
0
Fix Available
6.1.187-1,6.12.100-1,7.1.5-1

Fix Critical Vulnerabilities Instantly

Secure your app without upgrading.
Fix Without Upgrading