CVE-2026-43245

What it actually does

This Linux kernel NTFS filesystem flaw is an availability issue caused by NTFS name comparison and hashing paths performing potentially blocking memory allocation where the VFS d_compare() path must not sleep. Under specific NTFS pathname lookup conditions, the kernel can enter invalid blocking behavior in a non-blocking context, potentially causing kernel warnings, stalls, hung tasks, soft lockups, or system denial of service. The issue is in kernel NTFS handling rather than user-space NTFS tools, and confidentiality and integrity impact are not expected from the vulnerability as described.

Why it matters to the business

Systems that mount or process NTFS filesystems may be exposed to kernel-level instability or denial of service. A successful attack could disrupt workloads, storage access, virtual machine hosts, file-processing services, forensic tooling, removable-media workflows, or servers that automatically handle NTFS images or devices. Although this issue is not listed in CISA KEV, has no known public exploit maturity, and has a low EPSS score, the impact can still be operationally significant because a kernel hang or crash can interrupt all services running on the affected host.

How an attack unfolds

An attacker needs a way to cause an affected Linux kernel to perform NTFS directory entry comparison or hashing operations. In realistic scenarios, this may involve getting a crafted or unusual NTFS filesystem image, disk, removable device, virtual disk, or storage volume mounted and then triggering pathname lookups against it. During those lookups, the vulnerable NTFS code path may allocate memory using behavior that can block where blocking is not permitted. If triggered successfully, the result is not code execution but a kernel availability failure such as warnings, hung tasks, soft lockups, degraded responsiveness, or a denial-of-service condition requiring service restart or host reboot.

How to fix it

Upgrade the Linux kernel to a vendor-supported release that includes the NTFS fix replacing inappropriate names_cachep/__getname() usage with non-blocking allocation behavior for the affected NTFS d_compare() and d_hash() paths. Because no exact fixed package versions were provided, use the relevant Linux distribution or appliance vendor advisory to identify the corrected kernel build. Where immediate patching is not possible, reduce exposure by disabling automatic mounting of NTFS media, preventing untrusted users from mounting filesystems, restricting removable media and disk-image processing, avoiding in-kernel NTFS handling for untrusted content, and ensuring systems can be safely rebooted if a kernel hang occurs.

How to confirm the fix worked

Confirm the running kernel version is at or above the vendor-fixed build for this issue, not merely that an updated package is installed. Validate that NTFS automount behavior is disabled or restricted where NTFS support is not required. On representative patched systems, mount and access known-good NTFS test media and confirm normal operation without kernel warnings related to NTFS d_compare(), ntfs_d_hash(), sleeping in atomic context, hung tasks, or soft lockups. Review distribution changelogs or kernel commit history for the NTFS fix addressing non-blocking d_compare() behavior.

Typical attack path

1. Identify a Linux system that uses the in-kernel NTFS filesystem support or automatically processes NTFS media, disk images, or mounted volumes.
2. Deliver or expose a crafted NTFS filesystem, removable drive, virtual disk, or storage image to that system.
3. Cause the target system to mount or otherwise access the NTFS filesystem using the vulnerable kernel NTFS code.
4. Trigger NTFS pathname lookup, comparison, or hashing operations by accessing files or directories on the mounted NTFS volume.
5. Induce blocking allocation behavior in a non-blocking VFS comparison context.
6. Cause kernel instability, hung tasks, soft lockups, service interruption, or a denial-of-service condition.

How to detect it

Look for evidence that affected systems mounted or accessed NTFS filesystems shortly before instability, hangs, kernel warnings, or reboots. Useful log sources include kernel ring buffer output, journald, syslog, crash dumps, kdump/vmcore data, endpoint telemetry, hypervisor device-attachment logs, removable-media audit logs, and file-processing service logs for uploaded or mounted disk images. Search for NTFS-related call traces, sleeping-in-atomic-context warnings, hung task reports, soft lockup messages, allocation failures, and unexpected reboot or watchdog reset events. Correlate timestamps with mount events, udev events, loop-device attachments, removable media insertion, virtual disk attachment, or disk-image ingestion jobs. There are no known public threat actors or ransomware campaigns associated with this CVE in the provided data, so detection should focus on behavioral and forensic artifacts of kernel denial-of-service attempts rather than malware-specific signatures.

• ntfs_d_compare
• ntfs_d_hash
• BUG: sleeping function called from invalid context
• sleeping function called from invalid context
• watchdog: BUG: soft lockup
• BUG: soft lockup
• INFO: task
• blocked for more than
• hung_task_timeout_secs
• Call Trace:
• ntfs
• mount type ntfs
• type=ntfs
• /dev/loop
• systemd-udevd
• kernel: ntfs

What your security team should do

• Prioritize patching Linux systems that mount NTFS volumes, process user-supplied disk images, accept removable media, host virtualized storage workflows, or run file-analysis pipelines.
• Inventory systems with NTFS kernel module usage, NTFS automount rules, removable-media workflows, or disk-image ingestion paths.
• Disable or tightly restrict mounting of untrusted NTFS filesystems until patched.
• Ensure only privileged and trusted users can mount filesystems or attach block devices.
• Monitor kernel logs for NTFS-related warnings, hung tasks, sleeping-in-atomic-context messages, soft lockups, or unexplained reboots.
• For internet-facing or multi-tenant services that process uploaded disk images, isolate parsing and mounting workflows in disposable sandboxes or non-production hosts.
• Track vendor advisories for exact fixed kernel package versions and confirm systems have rebooted into the corrected kernel.