CVE-2025-71309: Linux Kernel NTFS3 Race Condition Flaw

CVE-2025-71309 Overview

CVE-2025-71309 is a deadlock vulnerability in the Linux kernel's fs/ntfs3 subsystem. The flaw exists in the ni_read_folio_cmpr() function (formerly ni_readpage_cmpr) and was reported by Syzbot. It stems from a lock inversion between the NTFS inode mutex (ni_lock) and VFS page locks during compressed folio reads.

When two tasks operate concurrently on pages within the same compressed frame, they can each hold one lock while waiting on the other. The result is an unrecoverable task hang on NTFS3 mounts that use compression.

Critical Impact

A local user with access to a compressed NTFS3 volume can trigger a kernel deadlock that hangs filesystem I/O and produces a denial-of-service condition.

Affected Products

• Linux kernel fs/ntfs3 driver (compressed NTFS read path)
• Distributions shipping vulnerable mainline and stable kernel branches prior to the fix commits
• Systems mounting NTFS volumes with compression enabled via the in-tree NTFS3 driver

Discovery Timeline

• 2026-05-27 - CVE-2025-71309 published to NVD
• 2026-05-27 - Last updated in NVD database

Technical Details for CVE-2025-71309

Vulnerability Analysis

The vulnerability is a classic lock inversion deadlock [CWE-833] in the NTFS3 compressed read path. The NTFS3 driver maintains an inode-level mutex ni_lock to serialize metadata operations. The VFS layer maintains per-page (folio) locks to coordinate concurrent I/O. When these two locks are acquired in inconsistent orders across kernel threads, forward progress halts.

Reading a compressed frame requires the driver to operate on every page belonging to that frame, not just the requested page. The original implementation in ntfs_read_folio() acquired ni_lock before locking the additional pages, violating the VFS convention that page locks precede inode locks. Readahead and direct read paths therefore race on the same frame.

The deadlock manifests as a stuck task in ni_read_folio_cmpr(). Affected processes accumulate in uninterruptible sleep and cannot be killed, eventually starving filesystem activity tied to the inode.

Root Cause

The root cause is incorrect lock ordering. ntfs_read_folio() took ni_lock first, then attempted to lock peer pages of the compressed frame inside ni_read_folio_cmpr(). Concurrent readers entering through readahead already hold a page lock and then block on ni_lock. Each task waits on a resource the other owns.

Attack Vector

The deadlock scenario described in the upstream commit message is as follows:

1. Task A enters ntfs_read_folio() for page X and acquires ni_lock.
2. Task A calls ni_read_folio_cmpr(), which tries to lock all pages in the compressed frame, including page Y.
3. Task B, executing readahead, has already locked page Y and calls ntfs_read_folio().
4. Task B blocks waiting for ni_lock held by Task A.
5. Task A blocks waiting for the page Y lock held by Task B.

Triggering the condition requires read access to a compressed NTFS3 volume. Syzbot reached the state via fuzzed filesystem images. No remote vector applies; the attack surface is local to systems that mount untrusted or shared NTFS3 media.

The vulnerability does not enable code execution, memory corruption, or privilege escalation. Impact is limited to denial of service through hung tasks. See the upstream fix commits for the precise locking restructure: Kernel commit cfe246b318 and Kernel commit e37a75bb866.

Detection Methods for CVE-2025-71309

Indicators of Compromise

• Kernel hung_task warnings naming ni_read_folio_cmpr or ni_readpage_cmpr in dmesg or /var/log/messages.
• Processes stuck in D state (uninterruptible sleep) when reading files on a compressed NTFS3 mount.
• khungtaskd log entries referencing the NTFS3 inode mutex and page lock waiters.

Detection Strategies

• Enable CONFIG_DETECT_HUNG_TASK and review kernel logs for stack traces involving ni_read_folio_cmpr, ntfs_read_folio, and __lock_page.
• Use echo w > /proc/sysrq-trigger to dump blocked tasks during a suspected hang and confirm the lock chain.
• Correlate filesystem hangs with the lockdep subsystem (CONFIG_PROVE_LOCKING) on test kernels to validate lock ordering on NTFS3 reads.

Monitoring Recommendations

• Forward kernel logs to a centralized logging or SIEM platform and alert on hung_task events referencing ntfs3 symbols.
• Track kernel versions across the fleet to identify hosts still running pre-patch builds with NTFS3 enabled.
• Audit mount tables (/proc/mounts) for NTFS3 filesystems mounted with the compression option on production hosts.

How to Mitigate CVE-2025-71309

Immediate Actions Required

• Update affected systems to a Linux kernel build that includes the upstream fix commits cfe246b318 and e37a75bb866.
• Avoid mounting untrusted or attacker-controlled NTFS3 images on production hosts until the patched kernel is deployed.
• Reboot hosts that exhibit hung NTFS3 tasks; the deadlock cannot be cleared without restarting affected processes or the system.

Patch Information

The fix restructures locking so ntfs_read_folio() no longer takes ni_lock. Instead, ni_read_folio_cmpr() acquires ni_lock only after all required page locks for the compressed frame have been obtained. This restores the VFS-consistent ordering of page lock followed by inode lock. Apply the kernel build that includes commit cfe246b318 and commit e37a75bb866, then validate with your distribution vendor.

Workarounds

• Disable the NTFS3 driver by unloading the ntfs3 module where NTFS access is not required.
• Mount NTFS volumes without compression, or migrate data to a non-compressed filesystem until patched.
• Restrict mount privileges so only trusted administrators can attach NTFS3 volumes to the host.

# Configuration example: prevent automatic loading of the vulnerable driver
echo 'blacklist ntfs3' | sudo tee /etc/modprobe.d/disable-ntfs3.conf
sudo modprobe -r ntfs3 || true

# Verify no NTFS3 mounts remain active
grep -E '\sntfs3\s' /proc/mounts || echo 'No ntfs3 mounts present'