CVE-2026-64532

What it actually does

This is a Linux kernel memory corruption vulnerability in the in-kernel NTFS3 filesystem driver. A malformed NTFS filesystem can place an out-of-range view.data_off value inside NTFS directory index structures. When the kernel processes NTFS log replay operations for UpdateRecordDataRoot or UpdateRecordDataAllocation, it can use that untrusted on-disk offset as the destination for memmove without first confirming that the write remains within the NTFS_DE entry. The result is an out-of-bounds kernel memory write. Because the flaw is in kernel code, successful exploitation can potentially cause a kernel crash, memory corruption, privilege escalation, or broader compromise of the host, depending on exploit reliability and kernel hardening.

Why it matters to the business

Systems that mount untrusted NTFS media or disk images are at risk of being crashed or potentially taken over by a local attacker or by a user who can persuade someone to attach or open a malicious NTFS-formatted device or image. The most exposed workflows are desktop endpoints, forensic workstations, file-ingest systems, virtualization hosts, backup/restore platforms, removable-media processing stations, and any Linux system that automatically mounts USB drives or disk images. This issue is not currently listed in CISA KEV, has no reported ransomware use, and has a low EPSS score, but it affects privileged kernel code and should be prioritized where NTFS mounting is enabled or user-controlled media is processed.

How an attack unfolds

An attacker prepares a specially crafted NTFS filesystem image or removable storage device containing malformed index records and log data. The malicious on-disk structures set an internal NTFS_DE view.data_off field so that, during NTFS log replay or metadata update handling, the kernel calculates a memmove destination outside the bounds of the intended entry. The attacker then needs the target system to mount or otherwise process the crafted NTFS filesystem using the vulnerable in-kernel ntfs3 driver. This may occur through user interaction, such as inserting a USB device, opening a disk image, attaching a virtual disk, or triggering an automount path. Once the vulnerable code path is reached, the kernel performs an out-of-bounds write. In the simplest case this causes a kernel oops or panic and denies service; with additional exploitation work, the memory corruption may be shaped toward local privilege escalation or kernel-level code execution.

How to fix it

Apply kernel updates from the relevant Linux distribution or kernel vendor as soon as they become available. Fixed package versions were not provided in the input, so remediation should be tracked through vendor advisories for the Linux kernel ntfs3 filesystem driver. Where immediate patching is not possible, reduce exposure by disabling or blacklisting the ntfs3 kernel module, preventing unprivileged users from mounting filesystems, disabling automount of removable media, blocking automatic processing of NTFS disk images, and routing untrusted NTFS media through isolated analysis systems. If NTFS support is required, consider using a less-privileged user-space mounting workflow where operationally acceptable, and ensure removable-media policies require explicit approval before mounting.

How to confirm the fix worked

Confirm the running kernel has received the vendor fix for the NTFS3 bounds check in UpdateRecordDataRoot and UpdateRecordDataAllocation. Validate both the installed kernel package and the actively booted kernel, because patched packages do not protect the system until the fixed kernel is running. Check whether the ntfs3 module is present or loaded using standard module inspection tools, and confirm that automount policies do not automatically mount NTFS media on systems that remain unpatched. For source-based validation, verify that the NTFS3 fslog handling checks that view.data_off plus the relevant data length remains within the NTFS_DE entry size before memmove is called. Avoid validating with weaponized filesystem images in production; use vendor test cases or controlled lab systems only.

Typical attack path

1. Attacker creates a malformed NTFS filesystem, disk image, virtual disk, or removable drive containing crafted NTFS index/log structures.
2. Attacker delivers the media or image to a target user, endpoint, ingestion service, forensic workstation, or virtualization workflow.
3. The target system mounts or scans the filesystem using the Linux kernel ntfs3 driver.
4. The NTFS3 driver processes UpdateRecordDataRoot or UpdateRecordDataAllocation log replay paths.
5. The malformed view.data_off value causes memmove to write beyond the bounds of the NTFS_DE structure.
6. The kernel experiences memory corruption, resulting in a crash, denial of service, or potentially privilege escalation if exploitation is reliable.

How to detect it

Detection should focus on evidence that vulnerable systems processed suspicious NTFS media or experienced kernel memory corruption shortly afterward. Review kernel logs, journald, syslog, auditd, EDR telemetry, USB device history, mount records, desktop automount logs, and virtualization or image-ingestion service logs. Look for NTFS or ntfs3 mounts involving removable devices, loop devices, downloaded disk images, virtual disks, or unexpected user-controlled paths. Correlate those events with kernel oops, panic, general protection fault, page fault, KASAN, UBSAN, or crash dump records referencing ntfs3, fslog, memmove, UpdateRecordDataRoot, or UpdateRecordDataAllocation. In production kernels, exploitation may leave only a crash or reboot artifact rather than a clean application log. Preserve the mounted image or removable device, crash dump, kernel ring buffer, and any automount or audit records for forensic review. There is no public KEV listing, known ransomware association, or named threat actor activity in the supplied data, so detection should be behavior- and artifact-driven rather than actor-specific.

• ntfs3
• UpdateRecordDataRoot
• UpdateRecordDataAllocation
• fs/ntfs3
• fslog.c
• view.data_off
• BUG: KASAN:
• slab-out-of-bounds
• out-of-bounds
• kernel BUG
• Oops:
• Kernel panic
• general protection fault
• unable to handle page fault
• memmove
• mount -t ntfs3
• type ntfs3
• /dev/loop
• /dev/sd

What your security team should do

• Prioritize patching Linux endpoints and servers that mount removable media, disk images, virtual disks, backups, or user-supplied NTFS filesystems.
• Identify systems where the in-kernel ntfs3 driver is available, loaded, or used in mount policies.
• Disable or blacklist ntfs3 on systems that do not require NTFS support.
• Disable automatic mounting of USB storage, external drives, and downloaded disk images, especially on unpatched systems.
• Restrict filesystem mounting privileges to trusted administrators and approved services.
• Review EDR, audit, and system logs for recent NTFS mounts, loop-device mounts, USB storage insertions, and kernel crashes involving ntfs3.
• Use isolated sandbox or forensic workstations for handling untrusted storage media and disk images.
• Track distribution-specific kernel advisories because exact fixed versions were not provided.
• Reboot systems after kernel updates and verify the fixed kernel is the active running kernel.
• Treat unexpected kernel oops, panic, or KASAN reports involving ntfs3 as potential exploitation or malformed-media events until investigated.