CVE-2025-71201
Unknown Unknown - Not Provided
Use-After-Free in Linux Kernel netfs Page Unlock Causes Data Leakage

Publication date: 2026-02-14

Last updated on: 2026-03-17

Assigner: kernel.org

Description
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.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-02-14
Last Modified
2026-03-17
Generated
2026-05-07
AI Q&A
2026-02-14
EPSS Evaluated
2026-05-05
NVD
CVE-2025-71201
EUVD
EUVD-2025-206908
Affected Vendors & Products
Showing 5 associated CPEs
Vendor Product Version / Range
linux linux_kernel 6.19
linux linux_kernel 6.19
linux linux_kernel 6.19
linux linux_kernel 6.19
linux linux_kernel From 6.14 (inc) to 6.18.6 (exc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-125 The product reads data past the end, or before the beginning, of the intended buffer.
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability exists in the Linux kernel's netfs subsystem, specifically related to buffered reads. The issue occurs because the read result collection can proceed ahead of the completion of subrequests under certain conditions. This leads to a situation where a page (folio) is unlocked early, even though some parts of the data (the tail) have not yet been cleared.

The problem arises because netfs_read_unlock_folios() unlocks a folio when the collected read results reach the end-of-file (EOF) position, but a ZERO subrequest that clears the tail of the page happens afterward. This allows applications to potentially see uncleared or stale data through memory mapping (mmap).

The fix involves changing the end check to always be the end of the folio (page) rather than the end of the file, ensuring the tail is cleared before unlocking. The ZERO subrequest is still necessary in some cases, such as handling file extents without backing storage.


How can this vulnerability impact me? :

This vulnerability can lead to applications reading uninitialized or stale data from memory-mapped files. Specifically, the tail end of a page may contain uncleared data, which could be garbage or sensitive leftover information.

Such exposure can cause data integrity issues or unintended information disclosure if sensitive data is present in the memory that should have been cleared before being accessible.


How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:

I don't know


How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability can be detected by observing the behavior of buffered reads in the Linux kernel's netfs subsystem, particularly when reading files whose size does not align to a page boundary.

A practical way to reproduce and detect the issue is by creating a file with a size that is not page-aligned (e.g., 24998 bytes) and performing memory-mapped reads on it.

The following command sequence can be used to test for the vulnerability:

  • xfs_io -c "mmap -r 0 0x6000" -c "madvise -d 0 0x6000" -c "mread -v 0 0x6000" /xfstest.test/x

If the last bytes of the file (e.g., last 0x4e bytes) are not zeroed out as expected, it indicates the vulnerability is present.


What immediate steps should I take to mitigate this vulnerability?

The vulnerability has been fixed in the Linux kernel by changing the end check to always be the end of the folio rather than the end of the file, ensuring proper clearing of the tail bytes.

Immediate mitigation steps include updating the Linux kernel to a version that contains this fix.

Since the issue relates to asynchronous handling of ZERO subrequests in netfs, avoiding or disabling affected asynchronous read operations temporarily may reduce exposure, but the primary and recommended action is to apply the kernel patch.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart