CVE-2026-45935

What it actually does

This is a Linux kernel memory-corruption flaw in the ntfs3 filesystem driver. During NTFS log replay, the kernel reads an index entry size from an NTFS log record and uses it to calculate memory movement boundaries without first proving that the entry fits inside the remaining index buffer. A maliciously large entry size can cause pointer arithmetic to move beyond the valid buffer, resulting in an incorrect large unsigned size being passed to memmove. In practical terms, mounting or otherwise processing a specially crafted NTFS filesystem can trigger a heap out-of-bounds read/write condition in kernel space, potentially causing kernel memory corruption, information disclosure, denial of service, or local privilege escalation depending on exploitability and kernel hardening.

Why it matters to the business

Systems that mount NTFS filesystems using the in-kernel ntfs3 driver may be exposed to compromise or crashes if a user, administrator, automation workflow, removable device, disk image, or virtualized storage source causes a malicious NTFS volume to be processed. The most likely operational impact is a kernel panic or system instability, but because the flaw occurs in kernel memory, successful exploitation could also allow an attacker to gain elevated privileges or tamper with system integrity. The CVSS score is high, but the currently reported EPSS is low, it is not listed in CISA KEV, and no public exploit maturity is reported, so urgency should be risk-based: prioritize systems that process untrusted removable media, disk images, forensic images, backup images, user-uploaded virtual disks, or dual-boot/shared NTFS storage.

How an attack unfolds

An attacker prepares a malformed NTFS filesystem containing a crafted log record that reaches the DeleteIndexEntryRoot path during ntfs3 journal/log replay. The malicious record supplies an index entry size that is larger than the remaining valid space in the index buffer. When a vulnerable kernel processes the volume, the ntfs3 driver calculates an out-of-bounds end pointer and then derives a memmove length from that invalid pointer relationship. Because the negative offset is interpreted as an unsigned size, the kernel attempts an excessively large memory operation, corrupting heap memory or triggering a kernel fault. The attacker needs a way to get the vulnerable system to process the crafted NTFS volume, such as a removable USB disk, attached block device, mounted disk image, VM image, or other local storage path that invokes the ntfs3 driver.

How to fix it

Apply a vendor-supplied Linux kernel update that includes the ntfs3 fix for the DeleteIndexEntryRoot bounds check. No exact fixed package versions were provided in the input, so use the fixed kernel releases from the relevant Linux distribution, appliance vendor, cloud image provider, or kernel maintainer. Where immediate patching is not possible, reduce exposure by preventing untrusted NTFS filesystems from being mounted, disabling desktop or server automount of removable media, restricting access to mount operations, avoiding use of the in-kernel ntfs3 driver for untrusted images, and processing untrusted disk images only in isolated sandboxes or disposable virtual machines. Consider blocking or tightly controlling USB mass-storage devices and untrusted virtual disk attachments on high-risk systems.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel version is at or above the vendor-fixed release and that the active booted kernel, not only an installed package, has been updated. Review vendor advisories or changelogs for references to the ntfs3 DeleteIndexEntryRoot bounds-check fix, slab-out-of-bounds in fs/ntfs3, or related NTFS log replay validation changes. Validate exposure by checking whether the ntfs3 module is present or loaded, whether NTFS volumes are mounted with filesystem type ntfs3, and whether automount policies allow untrusted NTFS media. On test systems only, kernel sanitizers such as KASAN can help validate that the specific slab-out-of-bounds condition no longer triggers when processing malformed NTFS test cases.

Typical attack path

1. Attacker creates a specially crafted NTFS filesystem with a malformed log record affecting the DeleteIndexEntryRoot action path.
2. Attacker delivers the crafted filesystem through removable media, a disk image, a virtual disk, shared storage, or another local mechanism that can be mounted or scanned by the target system.
3. A user, administrator, desktop automount service, forensic tool, backup process, VM workflow, or other local process causes the vulnerable Linux kernel to mount or inspect the NTFS volume using the ntfs3 driver.
4. During NTFS log replay or metadata processing, ntfs3 reads the malicious entry size without adequate bounds validation.
5. The kernel computes an out-of-bounds pointer and passes an invalid oversized length to memmove.
6. The system experiences kernel heap memory corruption, which may lead to a crash, information disclosure, or possible privilege escalation depending on exploit reliability and mitigations.

How to detect it

To determine whether exploitation may already have occurred, review kernel logs, system journals, crash dumps, and endpoint telemetry for ntfs3-related faults or memory-corruption symptoms around the time NTFS media, disk images, or virtual disks were attached or mounted. Useful sources include journalctl, dmesg, /var/log/kern.log, /var/log/messages, crash dump repositories, audit logs for mount activity, udev logs for removable media insertion, EDR device-control telemetry, and virtualization or backup platform logs showing disk image attachment. Look for kernel oops, panic, KASAN, KFENCE, UBSAN, general protection fault, BUG, or slab-out-of-bounds messages involving ntfs3, DeleteIndexEntryRoot, memmove, or NTFS index/log replay. Correlate these events with mount commands or automount activity for filesystem type ntfs3. Absence of these artifacts does not prove non-exploitation, because a successful kernel exploit may avoid obvious crashes, but crashes or sanitizer findings in this code path are strong indicators of attempted or accidental triggering.

• BUG: KASAN: slab-out-of-bounds
• slab-out-of-bounds read
• slab-out-of-bounds write
• fs/ntfs3
• ntfs3
• DeleteIndexEntryRoot
• do_action
• memmove
• general protection fault
• kernel BUG
• kernel panic
• Oops:
• RIP: *ntfs3
• RIP: *DeleteIndexEntryRoot
• mount -t ntfs3
• type ntfs3
• NTFS-fs error
• ntfs3:

What your security team should do

• Prioritize kernel updates for endpoints, workstations, forensic systems, virtualization hosts, backup servers, and file-processing systems that may mount untrusted NTFS volumes or disk images.
• Disable or restrict automount for removable media and untrusted block devices until patched, especially on Linux desktop fleets and shared administrative workstations.
• Inventory systems where the ntfs3 driver is loaded or where NTFS filesystems are mounted, and treat those as the primary exposure set.
• Require untrusted disk images, VM disks, backup media, and forensic images to be handled in isolated sandbox environments rather than on production hosts.
• Monitor kernel logs for ntfs3 crashes, KASAN findings, general protection faults, kernel oops messages, or panics occurring shortly after NTFS media insertion or mount events.
• Review USB/removable media control policies and enforce device restrictions where practical.
• Because this issue is not currently KEV-listed and has low EPSS, use risk-based scheduling, but do not defer patching on systems that routinely process untrusted storage.