CVE-2026-43127

What it actually does

This Linux kernel flaw is a local availability issue in the ntfs3 filesystem driver. A circular lock dependency can occur when NTFS metadata operations acquire locks in opposite order: one path takes the NTFS inode run lock and then the bitmap lock, while another path takes the bitmap lock and then attempts to acquire the run lock during MFT zone refresh. Under the right local filesystem activity, this AB-BA locking pattern can deadlock kernel execution paths associated with ntfs3, causing affected operations, processes, or potentially the system to hang. The issue does not provide direct confidentiality or integrity impact and does not enable remote code execution or privilege escalation by itself.

Why it matters to the business

Systems that mount or manipulate NTFS volumes using the Linux ntfs3 driver may become unstable or unavailable if the deadlock is triggered. The most likely operational consequence is a local denial of service affecting workloads that rely on NTFS-formatted media, dual-boot/shared storage, removable drives, forensic workstations, backup workflows, or file-ingestion systems. Because exploitation requires local access and there is no known public exploitation or KEV listing, urgency is moderate; however, internet-facing services are not the primary concern, while shared Linux systems where untrusted users can mount or interact with NTFS filesystems deserve higher priority.

How an attack unfolds

An attacker with local access identifies a Linux system that has the ntfs3 filesystem driver available and can mount, access, or influence operations on an NTFS filesystem. The attacker then performs filesystem activity designed to exercise NTFS metadata allocation and run-list unpacking paths concurrently, such as operations that grow or modify NTFS metadata while other operations trigger MFT zone refresh behavior. If timing aligns, one kernel path holds the inode run lock and waits on the NTFS bitmap lock while another path holds the bitmap lock and waits on the inode run lock. This circular wait results in a deadlock. The attacker’s practical goal is denial of service: causing filesystem operations, affected kernel threads, or the host to hang until administrative intervention, service restart, unmount, or reboot is required.

How to fix it

Upgrade to a Linux kernel version that includes the ntfs3 fix for the circular locking dependency in run_unpack_ex(). The corrected behavior uses a non-blocking read lock attempt for the run_lock while holding the NTFS bitmap lock and skips the MFT zone refresh if the lock is contended, preventing the deadlock. If vendor fixed versions are not yet listed, obtain the latest security kernel update from the operating system or appliance vendor and verify that the patch for the ntfs3 run_unpack_ex deadlock is included. As interim mitigations, avoid mounting untrusted NTFS filesystems, restrict local users from mounting filesystems, disable or blacklist the ntfs3 module where NTFS support is not required, mount NTFS media only on isolated systems, and prefer trusted maintenance workflows for removable or externally supplied NTFS volumes.

How to confirm the fix worked

Confirm exposure by checking whether affected systems run a kernel with ntfs3 support and whether NTFS filesystems are mounted with the in-kernel ntfs3 driver. Validate remediation by confirming the running kernel package is updated to a vendor release containing the fix, then rebooting into the patched kernel if required. Review vendor changelogs or kernel commit history for the ntfs3 change that replaces blocking acquisition of run_lock in run_unpack_ex() with down_read_trylock() and skips ntfs_refresh_zone() when contended. Operationally, verify that NTFS mount and metadata-heavy file operations complete normally after patching and that kernel logs no longer show circular locking dependency or hung-task reports involving ntfs3, run_unpack_ex, ntfs_extend_mft, ntfs_refresh_zone, wnd->rw_lock, or file.run_lock.

Typical attack path

1. Gain local access to a Linux system, container host, workstation, or shared server where interaction with NTFS filesystems is possible.
2. Confirm that the kernel includes the ntfs3 driver and that an NTFS volume can be mounted or accessed.
3. Create or use an NTFS filesystem with activity that stresses metadata, MFT growth, allocation bitmap updates, or run-list processing.
4. Run concurrent file and metadata operations to increase the chance of hitting the lock-order inversion between ntfs_extend_mft() and run_unpack_ex().
5. Trigger the AB-BA deadlock condition in the ntfs3 driver.
6. Cause NTFS filesystem operations, involved tasks, or the broader system to become unresponsive, resulting in local denial of service.

How to detect it

This issue is a local denial-of-service condition, so detection should focus on signs of attempted triggering or successful deadlock rather than network indicators. Review kernel logs, system journal, dmesg output, crash dumps, and hung-task reports for lockdep circular locking warnings or blocked tasks involving ntfs3. Look for repeated NTFS mount activity, metadata-heavy file operations, or local user activity immediately before filesystem hangs. Relevant log sources include /var/log/kern.log, /var/log/messages, /var/log/syslog, journalctl -k, dmesg, auditd logs for mount activity, sudo logs, and EDR telemetry for local processes repeatedly creating, deleting, resizing, or copying files on NTFS mounts. On systems with crash collection enabled, examine vmcore, kdump, or pstore records for blocked kernel stacks referencing run_unpack_ex(), ntfs_extend_mft(), ntfs_refresh_zone(), wnd->rw_lock, file.run_lock, or ntfs3. Since there are no known public exploit artifacts or threat actor campaigns, absence of these strings does not prove safety, but their presence around outages should prompt investigation.

• possible circular locking dependency detected
• circular locking dependency
• INFO: task
• blocked for more than
• ntfs3
• run_unpack_ex
• ntfs_extend_mft
• ntfs_refresh_zone
• wnd->rw_lock
• file.run_lock
• sbi->used.bitmap
• down_read_trylock
• MFT zone
• lockdep
• soft lockup
• hung_task
• /var/log/kern.log
• /var/log/messages
• /var/log/syslog
• journalctl -k
• dmesg

What your security team should do

• Prioritize patching Linux systems that allow local users, automation, removable media, or ingestion pipelines to mount or process NTFS filesystems using ntfs3.
• Inventory systems with NTFS mounts by reviewing mount output, /proc/mounts, filesystem monitoring, and endpoint configuration for use of the ntfs3 driver.
• Restrict filesystem mounting privileges to administrators and trusted automation only, especially on shared servers and developer workstations.
• Temporarily disable or blacklist the ntfs3 kernel module on systems that do not require NTFS access.
• Treat untrusted NTFS images and removable drives as potentially unsafe; process them in isolated, patched analysis environments.
• Monitor kernel logs for hung tasks, lockdep warnings, soft lockups, or filesystem stalls involving ntfs3 functions.
• Because EPSS is very low and no known exploited status is reported, prioritize based on local-user exposure and business reliance on NTFS workflows rather than broad emergency response.