LiveActive security incident?Get immediate response
CVE Record

CVE-2025-71309: fs/ntfs3: fix deadlock in ni_read_folio_cmpr

In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: fix deadlock in ni_read_folio_cmpr Syzbot reported a task hung in ni_readpage_cmpr (now ni_read_folio_cmpr). This is caused by a lock inversion deadlock involving the inode mutex (ni_lock) and page locks. Scenario: 1. Task A enters ntfs_read_folio() for page X. It acquires ni_lock. 2. Task A calls ni_read_folio_cmpr(), which attempts to lock all pages in the compressed frame (including page Y). 3. Concurrently, Task B (e.g., via readahead) has locked page Y and calls ntfs_read_folio(). 4. Task B waits for ni_lock (held by A). 5. Task A waits for page Y lock (held by B). -> DEADLOCK. The fix is to restructure locking: do not take ni_lock in ntfs_read_folio(). Instead, acquire ni_lock inside ni_read_folio_cmpr() ONLY AFTER all required page locks for the frame have been successfully acquired. This restores the correct lock ordering (Page Lock -> ni_lock) consistent with VFS. [almaz.alexandrovich@paragon-software.com: ni_readpage_cmpr was renamed to ni_read_folio_cmpr]

UnknownCVSS not scoredNot KEV-listedUpdated
Glexia's TakeAutomated analysismoderate

Security readout for executives and security teams

Plain-English summary

CVE-2025-71309 is a Linux kernel NTFS3 filesystem deadlock. Affected systems can hang when reading compressed NTFS data under specific concurrent access conditions. The business impact is availability, not documented data theft or privilege escalation. Public sources do not provide CVSS, KEV listing, or distribution-specific status.

Executive priority

Treat as a targeted availability risk for Linux environments that mount NTFS media, especially untrusted or removable volumes. It is not supported by current sources as an internet-scale emergency. Patch through normal kernel maintenance, with faster handling where NTFS ingestion is business-critical.

Technical view

The bug is a lock inversion in fs/ntfs3 ni_read_folio_cmpr involving the inode mutex ni_lock and page locks. One task can hold ni_lock while waiting on a page, while another holds that page and waits on ni_lock. Kernel stable fixes restructure locking so page locks are acquired before ni_lock.

Likely exposure

Exposure appears limited to Linux systems running affected kernel versions or commits and using the in-kernel NTFS3 driver with compressed NTFS files. Systems mounting removable, dual-boot, backup, or untrusted NTFS volumes are more relevant. Exact downstream distribution exposure is not provided in the source bundle.

Exploitation context

The sources show a syzbot-reported hung task and a resolved kernel deadlock. They do not report active exploitation, public weaponization, KEV inclusion, remote reachability, or privilege escalation. Triggering requires the NTFS3 compressed-read locking scenario described in the kernel fix text.

Researcher notes

Evidence is limited to the CVE description and Linux stable commit references. The affected version data in the bundle is sparse and should be validated against upstream commits and downstream vendor backports. No CVSS, CWE, proof-of-concept, or KEV signal is provided.

Mitigation direction

  • Check vendor kernel advisories for CVE-2025-71309 applicability and fixed builds.
  • Update to a kernel containing the referenced stable NTFS3 locking fixes.
  • Limit mounting of untrusted NTFS volumes until patched.
  • Prioritize systems that process removable, user-supplied, or backup NTFS media.
  • Monitor kernels for hung task reports involving ntfs3 compressed reads.

Validation and detection

  • Inventory Linux hosts that use or can mount NTFS3 filesystems.
  • Map running kernel versions to vendor advisories and fixed stable commits.
  • Review logs for hung tasks mentioning ntfs_read_folio or ni_read_folio_cmpr.
  • Confirm patched kernels include the referenced NTFS3 lock-ordering change.
  • Verify operational controls around untrusted NTFS media handling.
Prepared
Confidence
medium
Sources
4

Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.

Potential ATT&CK relevance

Conservative CVE-to-ATT&CK context

These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.

ATT&CK lookup starting points

Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.

cve · low confidence lookup

CVE-2025-71309 mapping review

Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.

Open ATT&CK lookup
Vulnerability profileCVE Program record
Severity
Unknown
CVSS
Not scored
Known Exploited
No
Published
Official CVE source material

CNA and ADP enrichment extracted from CVE v5

These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.

0CVSS vectors
3Timeline events
0ADP providers
3Source links

Vulnerability timeline

Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.

  1. CVE reservedCVE Program

    The CVE ID was reserved by the assigning CNA.

  2. CVE publishedCVE Program

    The CVE record was published.

  3. CVE updatedCVE Program

    The CVE record metadata indicates this as the latest update time.

Affected products

Products and packages named in the record

VendorProductVersion / packageStatus
LinuxLinuxf35590ee26f5722bfe12cdff14396c4c057a8f74, f35590ee26f5722bfe12cdff14396c4c057a8f74unaffected
LinuxLinux6.19, 0, 6.19.4, 7.0affected
Weakness

CWE details

No CWE listed

CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.