CVE-2026-45864

What it actually does

This is a local denial-of-service flaw in the Linux kernel NTFS3 filesystem driver. When the kernel processes a write path for an NTFS filesystem, it may repeatedly receive the same "valid" file range value while handling the range between the current valid data length and the write position. Without a progress check, the loop can fail to advance and spin indefinitely or leave a task blocked while holding filesystem/inode-related locks. The practical impact is availability loss: affected systems may experience hung kernel tasks, stalled file I/O, high CPU consumption, lock contention, or broader service degradation when interacting with a crafted or malformed NTFS filesystem or NTFS file state.

Why it matters to the business

An attacker with local access and the ability to interact with an NTFS filesystem could cause affected Linux systems to hang or become partially unavailable. This is most relevant to desktops, workstations, forensic systems, file-processing servers, virtualization hosts, removable-media workflows, and any Linux environment that mounts untrusted NTFS volumes. The CVSS score is moderate, EPSS is very low, there is no known CISA KEV listing, and no public exploit maturity is reported, so broad internet-scale exploitation is unlikely; however, the operational impact can still be significant where local users, removable drives, disk images, or automated file ingestion pipelines are trusted to mount NTFS content.

How an attack unfolds

An attacker first needs local code execution or a workflow that causes the target Linux system to mount and write to an attacker-controlled NTFS filesystem, such as a removable drive, disk image, virtual disk, or supplied storage artifact. The attacker prepares NTFS metadata or file state that causes the NTFS3 driver's valid-data tracking logic to return the same value repeatedly during write processing. When the victim system performs the triggering file operation, execution enters the NTFS3 write path and the loop handling the valid range does not make progress. The affected kernel task can become stuck while holding locks, leading to hung tasks and degraded or unavailable filesystem operations. This vulnerability does not provide direct privilege escalation, code execution, or data disclosure by itself; its impact is denial of service.

How to fix it

Upgrade the Linux kernel to a version that includes the NTFS3 fix which detects a non-advancing valid value and returns an error instead of looping indefinitely. No exact fixed version was provided in the input, so use the fixed kernel packages from the relevant Linux distribution or vendor advisory. Where immediate patching is not possible, reduce exposure by avoiding the NTFS3 driver for untrusted media, disabling or restricting automatic mounting of NTFS filesystems, mounting removable media only on isolated systems, limiting local user access to NTFS mount workflows, and using operational controls to prevent untrusted disk images or removable drives from being mounted on production systems.

How to confirm the fix worked

Confirm that the running kernel package includes the vendor backport or upstream fix for the NTFS3 valid-range loop condition. Validate with the distribution security advisory, package changelog, or kernel commit history rather than relying only on the base kernel version, because vendors often backport fixes. Check whether the ntfs3 module is present or loaded using standard host inventory and kernel module tooling. Review whether systems automatically mount NTFS media or process NTFS disk images. After remediation, controlled regression testing should verify that malformed or edge-case NTFS writes fail safely with an error instead of causing hung tasks or blocked filesystem operations.

Typical attack path

1. Obtain local access to an affected Linux system, or supply an NTFS volume, disk image, virtual disk, or removable device that the system will mount.
2. Craft or manipulate NTFS filesystem metadata or file state so the NTFS3 driver repeatedly obtains the same valid range value during write handling.
3. Trigger a write operation against the affected NTFS filesystem or file range.
4. Cause the NTFS3 write path to enter a non-progressing loop or blocked state.
5. Induce hung kernel tasks, stalled filesystem I/O, lock contention, or service degradation on the affected host.

How to detect it

Look for evidence of prior exploitation or triggering in kernel logs, system journals, crash dumps, and endpoint telemetry. Relevant log sources include dmesg output, journald kernel messages, /var/log/kern.log, /var/log/messages, crash dump analysis, watchdog/hung-task alerts, and EDR process/device telemetry around removable media or disk-image mounting. Focus on hung task warnings involving NTFS3 functions, repeated filesystem write stalls, lock contention involving inode locks, and system unresponsiveness shortly after mounting or writing to an NTFS volume. Correlate events with insertion of removable media, loopback mounting of disk images, virtual disk attachment, or user activity involving NTFS filesystems. Since this is a denial-of-service condition and not a code-execution vulnerability, durable IOCs may be limited; detection should emphasize kernel stack traces, timing correlation, affected module use, and suspicious NTFS media handling rather than malware artifacts.

• INFO: task
• blocked for more than 143 seconds
• ntfs_file_write_iter
• fs/ntfs3/file.c
• inode_lock include/linux/fs.h
• rwbase_write_lock
• kernel/locking/rwbase_rt.c
• ntfs3
• task hung
• hung_task
• blocked for more than

What your security team should do

• Prioritize patching systems that mount NTFS filesystems from removable media, user-supplied disk images, virtualization workflows, forensic intake, backup ingestion, or file-processing pipelines.
• Obtain the fixed kernel package from the operating system or appliance vendor and schedule a reboot where required for the new kernel to take effect.
• Temporarily disable automatic mounting of NTFS media and restrict NTFS mount permissions until affected systems are patched.
• Inventory systems with the ntfs3 kernel module available or loaded, and identify business workflows that rely on NTFS write support.
• Monitor kernel logs for hung task reports and NTFS3 write-path stack traces, especially on systems exposed to untrusted storage media.
• Treat suspicious removable media, disk images, and virtual disks as untrusted input; inspect them in isolated environments before use on production systems.
• Because this issue is not listed in KEV, has very low EPSS, and has no reported exploit maturity, prioritize based on local exposure to untrusted NTFS content rather than internet-facing risk.