CVE-2026-46062

What it actually does

This vulnerability is an integer overflow in the Linux kernel ntfs3 filesystem driver, specifically in run_unpack() while validating NTFS runlist metadata against the volume boundary. A crafted NTFS filesystem can supply large logical cluster number and length values that wrap during addition, causing the boundary check to pass when it should fail. If the malformed filesystem is parsed or mounted, the kernel may operate on invalid filesystem metadata, potentially leading to memory corruption, kernel crash, or execution of unintended kernel-level behavior. Because the vulnerable code runs in kernel context, successful exploitation can affect confidentiality, integrity, and availability of the host.

Why it matters to the business

Systems that mount or inspect untrusted NTFS media or disk images may be exposed to a local kernel compromise or denial of service. This is most relevant to desktops, workstations, forensic analysis systems, file-ingestion pipelines, virtualization hosts, removable-media workflows, and servers that automatically process uploaded or attached disk images. The issue is not known to be exploited in the wild and has low current EPSS probability, but the kernel-level impact is high because a successful exploit can crash systems or potentially allow full host compromise.

How an attack unfolds

An attacker prepares a malicious NTFS volume, removable drive, virtual disk, or filesystem image with specially crafted runlist values. The crafted metadata uses values that cause lcn + len arithmetic to wrap around during ntfs3 validation, bypassing the intended volume boundary check. The attacker then convinces a user, service, or automated workflow to mount, preview, scan, or otherwise parse the NTFS filesystem using a vulnerable Linux kernel. When the ntfs3 driver processes the malformed runlist, it may access invalid kernel memory or corrupt kernel state. Depending on kernel configuration, exploit reliability, and surrounding mitigations, the result may range from a kernel panic to possible local privilege escalation or kernel-level code execution.

How to fix it

Apply a vendor-supplied Linux kernel update that includes the ntfs3 run_unpack() integer overflow fix. Because no universal fixed kernel version is provided, track the advisory for the specific distribution, appliance, cloud image, or embedded kernel in use and upgrade to the first patched kernel available from that vendor. Where immediate patching is not possible, reduce exposure by preventing automatic mounting of untrusted NTFS filesystems, disabling or blacklisting the ntfs3 kernel module if NTFS support is not required, using a safer isolated sandbox for filesystem inspection, and restricting access to removable media and uploaded disk images. If NTFS support is required, consider using hardened workflows that process untrusted images in disposable virtual machines or containers with limited host access, while recognizing that kernel filesystem parsing still occurs on the host if mounted directly.

How to confirm the fix worked

Confirm that systems are running a kernel build from the vendor that contains the ntfs3 run_unpack() overflow fix. Review distribution security advisories, kernel changelogs, or package metadata for the ntfs3 fix referencing integer overflow in run_unpack() or use of check_add_overflow() for the lcn + len boundary check. Verify whether the ntfs3 module is present and loadable, and whether systems automatically mount NTFS filesystems. On Linux, check the running kernel version, installed kernel packages, and loaded modules; if mitigation relies on disabling ntfs3, confirm that the module cannot be loaded and that NTFS automount policies are disabled or restricted. Where feasible, test patched kernels in a controlled environment with malformed NTFS test images and confirm they reject the filesystem safely without kernel crash.

Typical attack path

1. Attacker creates a malformed NTFS filesystem, disk image, virtual disk, or removable-media payload with crafted runlist metadata.
2. Attacker delivers the payload through removable media, downloaded image, uploaded file, shared archive, virtual machine disk, or forensic sample.
3. A vulnerable Linux system mounts or parses the NTFS content using the in-kernel ntfs3 driver.
4. The ntfs3 run_unpack() logic performs an overflowing lcn + len boundary calculation.
5. The overflow causes invalid metadata to bypass validation.
6. The kernel processes out-of-bounds or inconsistent filesystem state, potentially causing memory corruption, denial of service, or privilege-impacting behavior.

How to detect it

There are no public, reliable exploit-specific indicators for this issue. Retrospective detection should focus on evidence that vulnerable systems mounted or attempted to parse suspicious NTFS media or disk images, followed by kernel instability. Review kernel logs, system journals, crash dumps, endpoint telemetry, removable media audit logs, file upload or image-processing logs, virtualization platform logs, and forensic workstation activity. Look for ntfs3 messages, kernel oops or panic events, unexpected reboots, segfault-like kernel faults, or crashes temporally correlated with mounting NTFS volumes, attaching USB storage, loop-mounting disk images, opening virtual disks, or analyzing untrusted filesystem samples. If crash dumps are available, examine stack traces for ntfs3 functions such as run_unpack() and related runlist parsing paths. Because exploitation may not leave durable filesystem artifacts, absence of logs does not prove non-exploitation, especially if kernel logging or crash dump collection was not enabled.

What your security team should do

• Prioritize patching Linux endpoints and servers that mount removable media, process user-supplied disk images, run forensic tooling, host virtualization workflows, or perform file-ingestion/scanning of NTFS content.
• Inventory systems with the ntfs3 kernel module available or loaded and identify workflows that automatically mount NTFS volumes.
• Disable NTFS automounting for untrusted media and images until patched.
• Blacklist or remove the ntfs3 module on systems that do not require kernel NTFS support.
• Route untrusted filesystem samples through isolated, disposable analysis environments rather than mounting them directly on production systems.
• Monitor kernel logs for ntfs3-related crashes, warnings, oops messages, or panics, especially following insertion of removable media or processing of disk images.
• Educate support, forensic, and operations teams not to mount unknown NTFS images on shared or production Linux hosts.
• Track vendor kernel advisories because fixed versions vary by distribution and downstream kernel branch.