CVE-2026-64533

What it actually does

This is a Linux kernel memory-corruption flaw in the ntfs3 filesystem driver. When replaying NTFS log metadata, the kernel converts older DIR_PAGE_ENTRY_32 records into DIR_PAGE_ENTRY records and uses the on-disk lcns_follow value to calculate a memmove() length. Because that per-entry value is not properly bounded against the validated restart-table entry size, a malicious NTFS filesystem image can cause out-of-bounds memory access beyond the allocated restart-table buffer. Depending on kernel build, memory layout, and exploit reliability, this can result in kernel crash, information disclosure, or potential local privilege escalation through kernel memory corruption.

Why it matters to the business

Systems that mount untrusted NTFS media or disk images could be compromised or crashed by a specially crafted filesystem. The most likely operational risk is workstation or server denial of service when removable media, forensic images, VM disks, or loop-mounted NTFS images are processed. Because the vulnerable code runs in the kernel, successful exploitation may also allow full system compromise. The issue is not currently listed in CISA KEV, has no reported exploit maturity in the supplied data, and has a low EPSS score, but it is still important for environments that handle external storage, user-supplied disk images, or automated media mounting.

How an attack unfolds

An attacker prepares a malformed NTFS filesystem image containing crafted log-replay metadata. Specifically, the image includes a version 0 restart table with DIR_PAGE_ENTRY_32 records where lcns_follow is set larger than what the entry size can safely contain. The attacker then gets a target system to mount or otherwise process the image using the in-kernel ntfs3 driver, such as through removable media, a downloaded disk image, a VM disk, or an automated mount workflow. During mount or recovery, ntfs3 executes log_replay(), converts the records, and calculates a memmove() length from the attacker-controlled lcns_follow value. The oversized copy accesses memory outside the allocated restart-table buffer, potentially corrupting kernel memory or crashing the system. With additional heap-shaping and kernel-specific exploit work, the attacker may be able to turn the corruption into local privilege escalation.

How to fix it

Upgrade to a Linux kernel version or distribution package that includes the ntfs3 fix validating lcns_follow during log_replay() conversion. Because exact fixed package versions were not supplied, track the relevant vendor advisory or kernel changelog for the patch titled fs/ntfs3: validate lcns_follow in log_replay conversion. Until patched, avoid mounting untrusted NTFS filesystems with the in-kernel ntfs3 driver. Disable or blacklist the ntfs3 module where NTFS support is not required. Restrict automatic mounting of removable media and user-supplied disk images. For workflows that must inspect untrusted NTFS content, prefer an isolated sandbox, disposable VM, or userspace tooling rather than mounting directly in the host kernel. Standard mount hardening options such as nodev, nosuid, and noexec are useful defense-in-depth but do not prevent this kernel parsing vulnerability.

How to confirm the fix worked

Confirm that deployed kernels include the ntfs3 lcns_follow bounds-check patch or a vendor security update referencing this issue. Check whether ntfs3 support is present or loaded using /proc/filesystems, lsmod, modinfo ntfs3, kernel configuration, and distribution package metadata. Validate that automount policies do not mount untrusted NTFS media automatically on unpatched systems. In a controlled non-production lab, a regression test with malformed NTFS log metadata should fail safely rather than causing a kernel oops, panic, or ntfs3 out-of-bounds access. Review kernel logs after testing or patch deployment for absence of ntfs3-related crashes during NTFS mount/recovery operations.

Typical attack path

1. Craft a malicious NTFS filesystem image with malformed restart-table/log-replay metadata.
2. Set lcns_follow in a DIR_PAGE_ENTRY_32 record to exceed the maximum value implied by the entry size.
3. Deliver the image through removable media, a downloadable disk image, a VM disk, an archive containing a mountable image, or another workflow that causes local mounting.
4. Cause the target Linux system to mount or inspect the NTFS image using the kernel ntfs3 driver.
5. Trigger ntfs3 log replay during mount/recovery.
6. Abuse the out-of-bounds memmove() and subsequent metadata iteration to crash the kernel or attempt kernel-level code execution/privilege escalation.

How to detect it

Look for evidence that a system mounted or attempted to mount an NTFS filesystem shortly before a kernel crash, oops, panic, or suspicious privilege escalation. Primary log sources include the kernel ring buffer, journald kernel facility, /var/log/kern.log, /var/log/messages, /var/log/syslog, auditd records, endpoint telemetry, removable-media logs, desktop automount logs, and shell/process execution history for mount, udisks, losetup, guestmount, qemu-nbd, or forensic tooling. Investigate events where ntfs3 is loaded or invoked and immediately followed by log_replay errors, invalid metadata messages, slab corruption, KASAN reports, general protection faults, page faults, or panics. Correlate with physical USB insertion events, loop-device creation, disk-image downloads, VM disk attachment, or automated indexing/scanning of archives. Since no public exploit indicators or malware artifacts are supplied, detection should focus on behavioral signs: malformed NTFS images, crashes in ntfs3/log_replay/memmove paths, and anomalous mounting of untrusted NTFS media. Preserve suspicious NTFS images and removable media for offline analysis rather than remounting them on production systems.

• ntfs3
• log_replay
• DIR_PAGE_ENTRY_32
• lcns_follow
• memmove
• BUG: kernel NULL pointer dereference
• BUG: unable to handle page fault
• general protection fault
• kernel panic
• Oops:
• KASAN:
• slab-out-of-bounds
• use-after-free
• mount -t ntfs3
• /proc/filesystems
• /sys/module/ntfs3
• ntfs3.ko
• udisksd
• losetup
• qemu-nbd
• guestmount

What your security team should do

• Prioritize patching Linux endpoints and servers that mount removable media, user-provided disk images, VM disks, forensic images, or backup media formatted as NTFS.
• Inventory systems with ntfs3 enabled or loaded and identify where automatic NTFS mounting is allowed.
• Temporarily disable or blacklist ntfs3 on systems that do not require kernel-level NTFS support.
• Disable desktop and server automount behavior for untrusted removable media until patched.
• Route untrusted NTFS analysis through sandboxed VMs or disposable analysis hosts.
• Monitor kernel logs for ntfs3, log_replay, memmove, general protection fault, BUG, Oops, panic, or KASAN reports associated with NTFS mounts.
• Treat any kernel crash immediately following NTFS media insertion or NTFS image mounting as potentially malicious and preserve the media/image for forensic analysis.
• Track vendor advisories for exact fixed kernel package versions because fixed versions were not provided in the input.