CVE-2026-64432

What it actually does

This vulnerability is a Linux kernel ntfs3 filesystem bounds-checking flaw in NTFS journal replay. When a crafted NTFS volume is mounted, the kernel's ntfs3 driver may copy Logical Cluster Number values from an NTFS $LogFile action record into a Dirty Page Table entry without validating that the destination array has enough capacity. Attacker-controlled NTFS metadata can cause the calculated destination index to exceed the allocated page_lcns[] array, including through an underflow/wraparound condition when target_vcn is smaller than the Dirty Page Table entry's vcn. The result is a kernel slab out-of-bounds write during mount-time log replay, which can cause kernel memory corruption, denial of service, or potentially local privilege escalation depending on kernel configuration, heap layout, and exploit reliability.

Why it matters to the business

Systems that automatically or manually mount untrusted NTFS media or disk images can be crashed or potentially compromised by a malicious filesystem image. This is most relevant to Linux desktops, forensic workstations, file ingestion pipelines, virtualization hosts, backup/recovery tooling, removable-media workflows, and servers that mount user-supplied disk images. Although the vulnerability is local and requires a crafted NTFS image to be mounted, successful exploitation occurs in kernel context, so the operational consequence can be severe: system outage, data exposure, tampering, or full host compromise. The issue is not currently listed in CISA KEV and has low EPSS, so broad exploitation is not indicated, but exposure should still be treated seriously wherever untrusted NTFS volumes are processed.

How an attack unfolds

An attacker creates a malicious NTFS filesystem image with inconsistent journal replay metadata. Specifically, the image contains a Dirty Page Table entry whose recorded LCN capacity is smaller than the LCN count in a related action log record, or whose target VCN relationship causes an unsigned subtraction to wrap to a very large index. The attacker then gets a victim system or automated workflow to mount the image using the Linux ntfs3 driver. During mount, the kernel replays the NTFS $LogFile journal and enters the vulnerable log_replay() path. Because the vulnerable code fails to validate the target VCN delta and LCN count against the destination Dirty Page Table entry capacity, it writes past the end of the allocated slab object. In common failure scenarios this triggers a kernel oops, panic, or KASAN slab-out-of-bounds report; in a more controlled exploitation scenario, the memory corruption may be shaped to alter adjacent kernel heap data and potentially gain elevated privileges.

How to fix it

Upgrade to a Linux kernel version that includes the ntfs3 fix validating Dirty Page Table capacity, target VCN delta, and per-record LCN count during journal replay. If vendor fixed package versions are not available, apply the relevant distribution kernel security update as soon as it is released, or backport the upstream ntfs3 patch to maintained kernels. As interim mitigation, avoid mounting untrusted NTFS filesystems with the in-kernel ntfs3 driver; disable automatic mounting of removable media; process untrusted disk images only inside isolated virtual machines or disposable sandboxes; prefer read-only mounting where operationally feasible; and restrict who can mount filesystems. If NTFS support is not required, remove or block loading of the ntfs3 kernel module where possible.

How to confirm the fix worked

Confirm that systems are running a kernel build containing the ntfs3 bounds-validation fix for journal replay. Validate package status using the operating system vendor's security advisory and installed kernel package version, then reboot into the updated kernel. Check whether ntfs3 is available or loaded with commands such as `lsmod | grep ntfs3`, `modinfo ntfs3`, and by reviewing `/proc/filesystems`. For exposure validation, identify systems that mount NTFS media or disk images, especially those with automount services or user-controlled upload/mount workflows. In test environments only, regression validation can include mounting known malformed NTFS test images and confirming the kernel rejects the filesystem cleanly with an error rather than producing a kernel oops, panic, or KASAN slab-out-of-bounds report.

Typical attack path

1. Craft an NTFS volume or disk image with malicious $LogFile journal replay records and Dirty Page Table metadata.
2. Deliver the crafted NTFS image through removable media, archive attachment, file upload, forensic evidence package, virtual disk, or another workflow that may mount NTFS content.
3. Cause the target Linux system to mount the image using the in-kernel ntfs3 driver.
4. Trigger NTFS journal replay during mount.
5. Exploit the missing bounds check in log_replay() to perform an out-of-bounds write in kernel slab memory.
6. Cause a kernel crash or attempt to convert the memory corruption into privilege escalation or broader host compromise.

How to detect it

Review kernel, system, and crash logs for signs of ntfs3 failures during NTFS mount operations. Relevant sources include `dmesg`, `journalctl -k`, `/var/log/kern.log`, `/var/log/messages`, `/var/log/syslog`, crash dump infrastructure such as kdump/vmcore, endpoint telemetry showing mount commands, desktop automount logs, udev events, and file-ingestion or virtualization service logs. Look for kernel oops, panic, BUG, KASAN, or slab corruption messages that reference `fs/ntfs3`, `log_replay`, `$LogFile`, Dirty Page Table replay, or NTFS mount activity immediately before a crash. Investigate any crash correlated with newly attached removable media, uploaded disk images, virtual disk processing, or forensic image handling. Because exploitation artifacts may be limited to the malicious filesystem image and volatile kernel corruption, preserve the mounted image or physical media, collect full kernel logs, and retain crash dumps before reboot cleanup where possible.

• BUG: KASAN: slab-out-of-bounds in log_replay
• slab-out-of-bounds in log_replay
• fs/ntfs3
• ntfs3
• $LogFile
• Dirty Page Table
• Write of size 8
• task mount
• kernel BUG
• kernel panic
• Oops
• general protection fault
• mount -t ntfs3
• /proc/filesystems
• /sys/module/ntfs3

What your security team should do

• Prioritize patching Linux systems that mount removable media, user-supplied disk images, virtual disks, backups, or forensic evidence packages.
• Disable automount for removable media and untrusted disk images until patched.
• Restrict filesystem mounting privileges and review use of setuid helpers, desktop automount services, container privileges, and virtualization workflows that can mount host filesystems.
• Process untrusted NTFS content in isolated, disposable environments with no sensitive credentials or production access.
• Monitor kernel logs for ntfs3 mount failures, kernel oopses, panics, and slab-out-of-bounds reports associated with NTFS journal replay.
• If crashes are observed after mounting NTFS media, preserve the image, kernel logs, crash dumps, and timeline evidence for forensic analysis.
• Track distribution advisories for fixed kernel package versions and ensure systems reboot into the corrected kernel after installation.