CVE-2025-71201 in Linux
Summary
by MITRE • 02/14/2026
In the Linux kernel, the following vulnerability has been resolved:
netfs: Fix early read unlock of page with EOF in middle
The read result collection for buffered reads seems to run ahead of the completion of subrequests under some circumstances, as can be seen in the following log snippet:
9p_client_res: client 18446612686390831168 response P9_TREAD tag 0 err 0 ... netfs_sreq: R=00001b55[1] DOWN TERM f=192 s=0 5fb2/5fb2 s=5 e=0
... netfs_collect_folio: R=00001b55 ix=00004 r=4000-5000 t=4000/5fb2 netfs_folio: i=157f3 ix=00004-00004 read-done netfs_folio: i=157f3 ix=00004-00004 read-unlock netfs_collect_folio: R=00001b55 ix=00005 r=5000-5fb2 t=5000/5fb2 netfs_folio: i=157f3 ix=00005-00005 read-done netfs_folio: i=157f3 ix=00005-00005 read-unlock ... netfs_collect_stream: R=00001b55[0:] cto=5fb2 frn=ffffffff
netfs_collect_state: R=00001b55 col=5fb2 cln=6000 n=c netfs_collect_stream: R=00001b55[0:] cto=5fb2 frn=ffffffff
netfs_collect_state: R=00001b55 col=5fb2 cln=6000 n=8 ... netfs_sreq: R=00001b55[2] ZERO SUBMT f=000 s=5fb2 0/4e s=0 e=0
netfs_sreq: R=00001b55[2] ZERO TERM f=102 s=5fb2 4e/4e s=5 e=0
The 'cto=5fb2' indicates the collected file pos we've collected results to so far - but we still have 0x4e more bytes to go - so we shouldn't have collected folio ix=00005 yet. The 'ZERO' subreq that clears the tail happens after we unlock the folio, allowing the application to see the uncleared tail through mmap.
The problem is that netfs_read_unlock_folios() will unlock a folio in which the amount of read results collected hits EOF position - but the ZERO subreq lies beyond that and so happens after.
Fix this by changing the end check to always be the end of the folio and never the end of the file.
In the future, I should look at clearing to the end of the folio here rather than adding a ZERO subreq to do this. On the other hand, the ZERO subreq can run in parallel with an async READ subreq. Further, the ZERO subreq may still be necessary to, say, handle extents in a ceph file that don't have any backing store and are thus implicitly all zeros.
This can be reproduced by creating a file, the size of which doesn't align to a page boundary, e.g. 24998 (0x5fb2) bytes and then doing something like:
xfs_io -c "mmap -r 0 0x6000" -c "madvise -d 0 0x6000" \ -c "mread -v 0 0x6000" /xfstest.test/x
The last 0x4e bytes should all be 00, but if the tail hasn't been cleared yet, you may see rubbish there. This can be reproduced with kafs by modifying the kernel to disable the call to netfs_read_subreq_progress() and to stop afs_issue_read() from doing the async call for NETFS_READAHEAD. Reproduction can be made easier by inserting an mdelay(100) in netfs_issue_read() for the ZERO-subreq case.
AFS and CIFS are normally unlikely to show this as they dispatch READ ops asynchronously, which allows the ZERO-subreq to finish first. 9P's READ op is completely synchronous, so the ZERO-subreq will always happen after. It isn't seen all the time, though, because the collection may be done in a worker thread.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 05/06/2026
The vulnerability described in CVE-2025-71201 resides within the Linux kernel's network filesystem subsystem, specifically affecting how buffered reads are handled when processing file operations that do not align with page boundaries. This flaw manifests in the netfs framework where the read result collection process prematurely unlocks pages before all underlying subrequests have completed, particularly when encountering end-of-file conditions within the middle of a page. The issue is rooted in the timing of operations within the read completion pipeline, where folios are unlocked before the final zero-fill subrequest (ZERO) has been processed, potentially exposing uninitialized memory contents to applications accessing the file through memory mapping or direct read operations.
Technical exploitation of this vulnerability occurs when a file size does not align with page boundaries, such as a 24998-byte file (0x5fb2 bytes), which creates a scenario where the final portion of the file falls within a page that requires zero-filling. The kernel's read result collection mechanism incorrectly determines that it has completed collecting results up to the file's end position, but fails to account for the subsequent zero-fill operation that must occur to clear the remainder of the page. This misalignment leads to a race condition where the page unlock operation happens before the zero-fill subrequest completes, allowing applications to observe garbage data in the tail portion of the page instead of the expected zero values. The problem is exacerbated by the synchronous nature of 9P's READ operations, which prevents the zero-fill operation from completing before the page is unlocked, unlike asynchronous implementations in AFS and CIFS that typically complete the zero-fill operation first.
The operational impact of this vulnerability extends to data integrity and potential information disclosure risks, particularly in environments where network filesystems are heavily utilized. When applications perform memory mapping operations or read operations that extend beyond the actual file size, they may inadvertently access memory regions containing stale data from previous operations or kernel memory. This behavior can compromise system security by exposing sensitive information that should have been cleared or initialized to zero, potentially leading to privilege escalation or data leakage in scenarios where applications access network filesystems through memory mapping interfaces. The vulnerability affects systems using the 9P protocol for network filesystem access and is particularly relevant in virtualized environments or cloud computing scenarios where such filesystems are commonly deployed. The issue is classified under CWE-362 as a race condition, and aligns with ATT&CK technique T1552.001 for unsecured credentials, as it could potentially expose sensitive data through improper memory clearing mechanisms.
Mitigation strategies for this vulnerability involve implementing a more robust synchronization mechanism within the netfs subsystem to ensure that all subrequests, including zero-fill operations, complete before pages are unlocked and made available to applications. The fix requires modifying the end check logic to always consider the page boundary rather than the file boundary when determining when to unlock folios, effectively preventing premature unlock operations that could expose uninitialized memory. System administrators should ensure their kernels are updated with patches that address this specific timing issue, particularly in environments where network filesystems are heavily utilized or where applications rely on memory mapping operations that could be affected by the exposure of uninitialized memory contents. Additionally, monitoring systems should be configured to detect anomalous behavior in memory mapping operations that might indicate this vulnerability's exploitation, and security teams should review access controls and privilege boundaries to minimize potential impact from any information disclosure that may occur.