CVE-2026-46072

What it actually does

This is an out-of-bounds heap read in the Linux kernel ntfs3 filesystem driver. When parsing NTFS run-list data in an MFT attribute, run_unpack() validates that parsing has not reached the end of the buffer, but previously did not verify that the declared size and offset fields still fit in the remaining buffer before reading them. A malformed or truncated NTFS filesystem image can therefore cause the kernel to read beyond the allocated buffer during mount or metadata parsing. The most likely technical outcome is a kernel fault, panic, or denial of service; the published description indicates an out-of-bounds read of up to 15 bytes and does not indicate reliable code execution or data modification.

Why it matters to the business

Systems that allow users, administrators, automation, or removable-media workflows to mount untrusted NTFS images may be crashed by a malicious filesystem image, causing service interruption, failed jobs, or workstation/server downtime. Risk is highest for Linux endpoints, forensic workstations, file-processing pipelines, virtualization hosts, backup systems, or kiosks that automatically or routinely mount external disks or disk images. This issue is not in CISA KEV, has no known mature public exploit, and has a low EPSS score, so broad internet-scale exploitation is unlikely; however, local denial-of-service exposure remains relevant where untrusted storage media is handled.

How an attack unfolds

An attacker prepares a specially crafted NTFS volume or disk image with truncated run-list data inside an MFT attribute. The attacker then gets the target system to mount or otherwise parse that image using the in-kernel ntfs3 driver. During mount or metadata access, the kernel enters ntfs3 run-list parsing, trusts the encoded field sizes too far, and attempts to read past the end of the run buffer. Depending on kernel configuration and memory layout, this can trigger a KASAN report, general protection fault, oops, or kernel panic, resulting in a local denial of service. Exploitation generally requires local access or a workflow that processes attacker-controlled removable media or filesystem images.

How to fix it

Update the Linux kernel to a vendor release that includes the ntfs3 run_unpack() boundary-check fix. Because exact fixed package versions were not provided, use your Linux distribution or kernel vendor advisory to identify the first patched kernel for your release stream. If immediate patching is not possible, reduce exposure by preventing automatic mounting of untrusted NTFS media, disabling or restricting use of the in-kernel ntfs3 driver where operationally feasible, processing untrusted disk images only in isolated disposable virtual machines, and requiring explicit approval for mounting externally supplied NTFS volumes. Consider using hardened sandboxed analysis environments for forensic or file-intake workflows that must inspect untrusted filesystem images.

How to confirm the fix worked

Confirm that affected systems are running a kernel build that contains the ntfs3 boundary-check patch for run_unpack(). Validate through vendor package metadata, kernel changelogs, or source inspection showing bounds checks before each run_unpack_s64() call. Operationally, verify that untrusted NTFS media is not auto-mounted and that mount policies, udev rules, desktop automount settings, and image-processing pipelines do not invoke ntfs3 on attacker-controlled images without isolation. In test environments only, a known malformed NTFS image should no longer trigger KASAN, oops, panic, or ntfs3 parsing failures after the patched kernel is installed.

Typical attack path

1. Create a malformed NTFS filesystem image containing truncated run data in an MFT attribute.
2. Deliver the image through removable media, a downloaded disk image, an uploaded forensic sample, a VM image, or another workflow that mounts untrusted filesystems.
3. Cause the target Linux system to mount or inspect the image with the ntfs3 kernel driver.
4. Trigger ntfs3 run-list parsing during mount or metadata access.
5. Induce an out-of-bounds heap read that may crash the kernel or destabilize the system.

How to detect it

Review kernel and system logs for ntfs3 activity immediately preceding crashes, oopses, panics, or KASAN reports. Useful sources include journald, dmesg, /var/log/kern.log, /var/log/messages, audit logs for mount activity, EDR telemetry for mount commands, and desktop or udev automount logs. Look for a sequence where an NTFS mount or image attachment is followed by kernel memory-safety diagnostics, general protection faults, page faults, soft lockups, or reboots. In environments that process uploaded or removable disk images, correlate suspicious crashes with the source image, user session, USB insertion event, loop-device setup, or mount namespace activity. Because the vulnerability is triggered by malformed filesystem contents, there may be no network indicator; the most useful forensic artifacts are the mounted NTFS image/device, shell or service history showing mount/losetup/udisks activity, and kernel crash traces referencing ntfs3 or run-list parsing.

• ntfs3
• run_unpack
• run_unpack_s64
• BUG: KASAN: slab-out-of-bounds
• KASAN: slab-out-of-bounds
• general protection fault
• kernel BUG
• Oops:
• Kernel panic
• RIP: 0010:run_unpack
• RIP: 0010:run_unpack_s64
• RIP: 0010:ntfs
• mount -t ntfs3
• fstype=ntfs3
• udisksd
• losetup

What your security team should do

• Prioritize patching Linux systems that mount removable media, process disk images, run forensic tooling, host virtualization workflows, or accept user-supplied filesystem images.
• Inventory systems with ntfs3 support enabled and identify workflows that mount NTFS volumes automatically or on behalf of less-trusted users.
• Disable desktop, udev, or service-level automounting of untrusted NTFS media where not required.
• Route untrusted NTFS image analysis through isolated disposable virtual machines or sandboxed hosts until patching is complete.
• Monitor kernel logs for ntfs3-related crashes, KASAN reports, oopses, or panics following NTFS mount activity.
• Treat unexpected kernel crashes during NTFS mount or image inspection as potentially malicious and preserve the source media/image for forensic review.