Skip to content
Fencer Vulns
high 7.1

CVE-2025-71201 json

netfs: Fix early read unlock of page with EOF in middle

published 2026-02-14 8 mo ago modified 2026-08-05 3 mo ago also EUVD-2025-206908

cvss
7.1
version 3.1, CNA
cisa kev
Not listed
not in CISA's catalog
epss
0.1%
EPSS 0.1% chance of exploitation in 30 days, percentile 3%
public exploits
0
none known

Summary

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.

Patch / fix

  • Linux Linux 6.18.6, 6.19
  • linux Debian 14 6.18.8-1

debian advisories DEBIAN-CVE-2025-71201

  • linux-gcp-6.17 Ubuntu 24.04 LTS 6.17.0-1021.24~24.04.1
  • linux-hwe-6.17 Ubuntu 24.04 LTS 6.17.0-41.41~24.04.1
  • linux-oem-6.17 Ubuntu 24.04 LTS 6.17.0-1030.30
  • linux-azure-6.17 Ubuntu 24.04 LTS 6.17.0-1021.21~24.04.1
  • linux-nvidia-6.17 Ubuntu 24.04 LTS 6.17.0-1031.31
  • linux-oracle-6.17 Ubuntu 24.04 LTS 6.17.0-1019.19~24.04.3
  • linux-realtime-6.17 Ubuntu Pro Realtime 24.04 LTS 6.17.0-1018.20~24.04.1

ubuntu advisories UBUNTU-CVE-2025-71201

Ubuntu security data © Canonical Ltd., from https://github.com/canonical/ubuntu-security-notices via OSV; changed: normalised to fixed package versions per release. CC BY-SA 4.0

  • kernel RHEL 10.1 6.12.0-124.8.1.el10_1
  • rv RHEL 10.1 6.12.0-124.8.1.el10_1
  • perf RHEL 10.1 6.12.0-124.8.1.el10_1
  • rtla RHEL 10.1 6.12.0-124.8.1.el10_1
  • libperf RHEL 10.1 6.12.0-124.8.1.el10_1
  • kernel-rt RHEL 10.1 6.12.0-124.8.1.el10_1
  • kernel-64k RHEL 10.1 6.12.0-124.8.1.el10_1
  • kernel-core RHEL 10.1 6.12.0-124.8.1.el10_1

red hat advisories RHSA-2025:20095

Vendor advisories

What the vendors themselves say about their products: affected, fixed or not affected, and what to do.

red hat product security vex CVE-2025-71201 updated cvss 4.7

kernel: netfs: Fix early read unlock of page with EOF in middle

  • Red Hat Enterprise Linux AppStream (v. 10) rv 6.12.0-124.8.1.el10_1, perf 6.12.0-124.8.1.el10_1, rtla 6.12.0-124.8.1.el10_1, python3-perf 6.12.0-124.8.1.el10_1, kernel-devel-matched 6.12.0-124.8.1.el10_1, kernel-64k-devel-matched 6.12.0-124.8.1.el10_1, +7 more Red Hat Enterprise Linux BaseOS (v. 10) kernel 6.12.0-124.8.1.el10_1, kernel-64k 6.12.0-124.8.1.el10_1, kernel-core 6.12.0-124.8.1.el10_1, kernel-tools 6.12.0-124.8.1.el10_1, kernel-modules 6.12.0-124.8.1.el10_1, kernel-64k-core 6.12.0-124.8.1.el10_1, +28 more Red Hat Enterprise Linux CodeReady Linux Builder (v. 10) libperf 6.12.0-124.8.1.el10_1, kernel-debuginfo-common-s390x 6.12.0-124.8.1.el10_1, kernel-debuginfo-common-x86_64 6.12.0-124.8.1.el10_1, kernel-debuginfo-common-aarch64 6.12.0-124.8.1.el10_1, kernel-debuginfo-common-ppc64le 6.12.0-124.8.1.el10_1 Red Hat Enterprise Linux Real Time (v. 10) kernel-rt 6.12.0-124.8.1.el10_1, kernel-rt-64k 6.12.0-124.8.1.el10_1, kernel-rt-core 6.12.0-124.8.1.el10_1, kernel-rt-modules 6.12.0-124.8.1.el10_1, kernel-rt-64k-core 6.12.0-124.8.1.el10_1, kernel-rt-debug-core 6.12.0-124.8.1.el10_1, +14 more Red Hat Enterprise Linux Real Time for NFV (v. 10) kernel-rt 6.12.0-124.8.1.el10_1, kernel-rt-core 6.12.0-124.8.1.el10_1, kernel-rt-modules 6.12.0-124.8.1.el10_1, kernel-rt-debug-core 6.12.0-124.8.1.el10_1, kernel-rt-modules-core 6.12.0-124.8.1.el10_1, kernel-rt-debug-modules 6.12.0-124.8.1.el10_1, +4 more
    fixed: vendor fix RHSA-2025:20095
  • Red Hat Enterprise Linux 6 perf, kernel, python-perf, kernel-kdump, kernel-firmware, kernel-bootwrapper, +1 more Red Hat Enterprise Linux 7 perf, kernel, bpftool, kernel-rt, python-perf, kernel-kdump, +8 more Red Hat Enterprise Linux 8 perf, kernel, bpftool, kernel-rt, kernel-core, kernel-tools, +29 more Red Hat Enterprise Linux 9 rv, perf, rtla, kernel, bpftool, libperf, +83 more
    not affected: vulnerable code not present

Red Hat CSAF VEX © Red Hat, Inc., from https://security.access.redhat.com/data/csaf/v2/vex/; changed: reduced to product statuses and remediations. CC BY 4.0 · csaf

Exploit prediction

0.14% chance of exploitation in the next 30 days, higher than 3% of all scored CVEs (FIRST EPSS, 2026-11-08).

CVSS scores

assigned by version score vector
CNA 3.1 7.1 CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
NVD 3.1 7.1 CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H

Affected products

  • Linux Linux

Classification

Weakness
Technology feeds

References

Sources

Fencer Vulns keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.