CVE-2025-71201 (GCVE-0-2025-71201)
Vulnerability from cvelistv5 – Published: 2026-02-14 15:22 – Updated: 2026-02-14 15:22
VLAI?
Title
netfs: Fix early read unlock of page with EOF in middle
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.
Severity ?
No CVSS data available.
Assigner
References
Impacted products
{
"containers": {
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"fs/netfs/read_collect.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "5b5482c0e5ee740b35a70759d3582477aea8e8e4",
"status": "affected",
"version": "e2d46f2ec332533816417b60933954173f602121",
"versionType": "git"
},
{
"lessThan": "570ad253a3455a520f03c2136af8714bc780186d",
"status": "affected",
"version": "e2d46f2ec332533816417b60933954173f602121",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"fs/netfs/read_collect.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "6.14"
},
{
"lessThan": "6.14",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.18.*",
"status": "unaffected",
"version": "6.18.6",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.19",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.18.6",
"versionStartIncluding": "6.14",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.19",
"versionStartIncluding": "6.14",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnetfs: Fix early read unlock of page with EOF in middle\n\nThe read result collection for buffered reads seems to run ahead of the\ncompletion of subrequests under some circumstances, as can be seen in the\nfollowing log snippet:\n\n 9p_client_res: client 18446612686390831168 response P9_TREAD tag 0 err 0\n ...\n netfs_sreq: R=00001b55[1] DOWN TERM f=192 s=0 5fb2/5fb2 s=5 e=0\n ...\n netfs_collect_folio: R=00001b55 ix=00004 r=4000-5000 t=4000/5fb2\n netfs_folio: i=157f3 ix=00004-00004 read-done\n netfs_folio: i=157f3 ix=00004-00004 read-unlock\n netfs_collect_folio: R=00001b55 ix=00005 r=5000-5fb2 t=5000/5fb2\n netfs_folio: i=157f3 ix=00005-00005 read-done\n netfs_folio: i=157f3 ix=00005-00005 read-unlock\n ...\n netfs_collect_stream: R=00001b55[0:] cto=5fb2 frn=ffffffff\n netfs_collect_state: R=00001b55 col=5fb2 cln=6000 n=c\n netfs_collect_stream: R=00001b55[0:] cto=5fb2 frn=ffffffff\n netfs_collect_state: R=00001b55 col=5fb2 cln=6000 n=8\n ...\n netfs_sreq: R=00001b55[2] ZERO SUBMT f=000 s=5fb2 0/4e s=0 e=0\n netfs_sreq: R=00001b55[2] ZERO TERM f=102 s=5fb2 4e/4e s=5 e=0\n\nThe \u0027cto=5fb2\u0027 indicates the collected file pos we\u0027ve collected results to\nso far - but we still have 0x4e more bytes to go - so we shouldn\u0027t have\ncollected folio ix=00005 yet. The \u0027ZERO\u0027 subreq that clears the tail\nhappens after we unlock the folio, allowing the application to see the\nuncleared tail through mmap.\n\nThe problem is that netfs_read_unlock_folios() will unlock a folio in which\nthe amount of read results collected hits EOF position - but the ZERO\nsubreq lies beyond that and so happens after.\n\nFix this by changing the end check to always be the end of the folio and\nnever the end of the file.\n\nIn the future, I should look at clearing to the end of the folio here rather\nthan adding a ZERO subreq to do this. On the other hand, the ZERO subreq can\nrun in parallel with an async READ subreq. Further, the ZERO subreq may still\nbe necessary to, say, handle extents in a ceph file that don\u0027t have any\nbacking store and are thus implicitly all zeros.\n\nThis can be reproduced by creating a file, the size of which doesn\u0027t align\nto a page boundary, e.g. 24998 (0x5fb2) bytes and then doing something\nlike:\n\n xfs_io -c \"mmap -r 0 0x6000\" -c \"madvise -d 0 0x6000\" \\\n -c \"mread -v 0 0x6000\" /xfstest.test/x\n\nThe last 0x4e bytes should all be 00, but if the tail hasn\u0027t been cleared\nyet, you may see rubbish there. This can be reproduced with kafs by\nmodifying the kernel to disable the call to netfs_read_subreq_progress()\nand to stop afs_issue_read() from doing the async call for NETFS_READAHEAD.\nReproduction can be made easier by inserting an mdelay(100) in\nnetfs_issue_read() for the ZERO-subreq case.\n\nAFS and CIFS are normally unlikely to show this as they dispatch READ ops\nasynchronously, which allows the ZERO-subreq to finish first. 9P\u0027s READ op is\ncompletely synchronous, so the ZERO-subreq will always happen after. It isn\u0027t\nseen all the time, though, because the collection may be done in a worker\nthread."
}
],
"providerMetadata": {
"dateUpdated": "2026-02-14T15:22:21.233Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/5b5482c0e5ee740b35a70759d3582477aea8e8e4"
},
{
"url": "https://git.kernel.org/stable/c/570ad253a3455a520f03c2136af8714bc780186d"
}
],
"title": "netfs: Fix early read unlock of page with EOF in middle",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2025-71201",
"datePublished": "2026-02-14T15:22:21.233Z",
"dateReserved": "2026-01-31T11:36:51.193Z",
"dateUpdated": "2026-02-14T15:22:21.233Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2",
"vulnerability-lookup:meta": {
"nvd": "{\"cve\":{\"id\":\"CVE-2025-71201\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2026-02-14T16:15:52.647\",\"lastModified\":\"2026-02-18T17:52:44.520\",\"vulnStatus\":\"Awaiting Analysis\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"In the Linux kernel, the following vulnerability has been resolved:\\n\\nnetfs: Fix early read unlock of page with EOF in middle\\n\\nThe read result collection for buffered reads seems to run ahead of the\\ncompletion of subrequests under some circumstances, as can be seen in the\\nfollowing log snippet:\\n\\n 9p_client_res: client 18446612686390831168 response P9_TREAD tag 0 err 0\\n ...\\n netfs_sreq: R=00001b55[1] DOWN TERM f=192 s=0 5fb2/5fb2 s=5 e=0\\n ...\\n netfs_collect_folio: R=00001b55 ix=00004 r=4000-5000 t=4000/5fb2\\n netfs_folio: i=157f3 ix=00004-00004 read-done\\n netfs_folio: i=157f3 ix=00004-00004 read-unlock\\n netfs_collect_folio: R=00001b55 ix=00005 r=5000-5fb2 t=5000/5fb2\\n netfs_folio: i=157f3 ix=00005-00005 read-done\\n netfs_folio: i=157f3 ix=00005-00005 read-unlock\\n ...\\n netfs_collect_stream: R=00001b55[0:] cto=5fb2 frn=ffffffff\\n netfs_collect_state: R=00001b55 col=5fb2 cln=6000 n=c\\n netfs_collect_stream: R=00001b55[0:] cto=5fb2 frn=ffffffff\\n netfs_collect_state: R=00001b55 col=5fb2 cln=6000 n=8\\n ...\\n netfs_sreq: R=00001b55[2] ZERO SUBMT f=000 s=5fb2 0/4e s=0 e=0\\n netfs_sreq: R=00001b55[2] ZERO TERM f=102 s=5fb2 4e/4e s=5 e=0\\n\\nThe \u0027cto=5fb2\u0027 indicates the collected file pos we\u0027ve collected results to\\nso far - but we still have 0x4e more bytes to go - so we shouldn\u0027t have\\ncollected folio ix=00005 yet. The \u0027ZERO\u0027 subreq that clears the tail\\nhappens after we unlock the folio, allowing the application to see the\\nuncleared tail through mmap.\\n\\nThe problem is that netfs_read_unlock_folios() will unlock a folio in which\\nthe amount of read results collected hits EOF position - but the ZERO\\nsubreq lies beyond that and so happens after.\\n\\nFix this by changing the end check to always be the end of the folio and\\nnever the end of the file.\\n\\nIn the future, I should look at clearing to the end of the folio here rather\\nthan adding a ZERO subreq to do this. On the other hand, the ZERO subreq can\\nrun in parallel with an async READ subreq. Further, the ZERO subreq may still\\nbe necessary to, say, handle extents in a ceph file that don\u0027t have any\\nbacking store and are thus implicitly all zeros.\\n\\nThis can be reproduced by creating a file, the size of which doesn\u0027t align\\nto a page boundary, e.g. 24998 (0x5fb2) bytes and then doing something\\nlike:\\n\\n xfs_io -c \\\"mmap -r 0 0x6000\\\" -c \\\"madvise -d 0 0x6000\\\" \\\\\\n -c \\\"mread -v 0 0x6000\\\" /xfstest.test/x\\n\\nThe last 0x4e bytes should all be 00, but if the tail hasn\u0027t been cleared\\nyet, you may see rubbish there. This can be reproduced with kafs by\\nmodifying the kernel to disable the call to netfs_read_subreq_progress()\\nand to stop afs_issue_read() from doing the async call for NETFS_READAHEAD.\\nReproduction can be made easier by inserting an mdelay(100) in\\nnetfs_issue_read() for the ZERO-subreq case.\\n\\nAFS and CIFS are normally unlikely to show this as they dispatch READ ops\\nasynchronously, which allows the ZERO-subreq to finish first. 9P\u0027s READ op is\\ncompletely synchronous, so the ZERO-subreq will always happen after. It isn\u0027t\\nseen all the time, though, because the collection may be done in a worker\\nthread.\"},{\"lang\":\"es\",\"value\":\"En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:\\n\\nnetfs: Soluci\u00f3n para el desbloqueo temprano de lectura de p\u00e1gina con EOF en el medio\\n\\nLa recopilaci\u00f3n de resultados de lectura para lecturas en b\u00fafer parece adelantarse a la finalizaci\u00f3n de las subpeticiones bajo algunas circunstancias, como se puede ver en el siguiente fragmento de registro:\\n\\n 9p_client_res: cliente 18446612686390831168 response P9_TREAD tag 0 err 0\\n ...\\n netfs_sreq: R=00001b55[1] DOWN TERM f=192 s=0 5fb2/5fb2 s=5 e=0\\n ...\\n netfs_collect_folio: R=00001b55 ix=00004 r=4000-5000 t=4000/5fb2\\n netfs_folio: i=157f3 ix=00004-00004 read-done\\n netfs_folio: i=157f3 ix=00004-00004 read-unlock\\n netfs_collect_folio: R=00001b55 ix=00005 r=5000-5fb2 t=5000/5fb2\\n netfs_folio: i=157f3 ix=00005-00005 read-done\\n netfs_folio: i=157f3 ix=00005-00005 read-unlock\\n ...\\n netfs_collect_stream: R=00001b55[0:] cto=5fb2 frn=ffffffff\\n netfs_collect_state: R=00001b55 col=5fb2 cln=6000 n=c\\n netfs_collect_stream: R=00001b55[0:] cto=5fb2 frn=ffffffff\\n netfs_collect_state: R=00001b55 col=5fb2 cln=6000 n=8\\n ...\\n netfs_sreq: R=00001b55[2] ZERO SUBMT f=000 s=5fb2 0/4e s=0 e=0\\n netfs_sreq: R=00001b55[2] ZERO TERM f=102 s=5fb2 4e/4e s=5 e=0\\n\\nEl \u0027cto=5fb2\u0027 indica la posici\u00f3n de archivo recopilada a la que hemos recogido resultados hasta ahora, pero a\u00fan nos quedan 0x4e bytes m\u00e1s, por lo que no deber\u00edamos haber recopilado el folio ix=00005 todav\u00eda. La subpetici\u00f3n \u0027ZERO\u0027 que borra la cola ocurre despu\u00e9s de que desbloqueamos el folio, permitiendo que la aplicaci\u00f3n vea la cola no borrada a trav\u00e9s de mmap.\\n\\nEl problema es que netfs_read_unlock_folios() desbloquear\u00e1 un folio en el que la cantidad de resultados de lectura recopilados alcanza la posici\u00f3n EOF, pero la subpetici\u00f3n ZERO se encuentra m\u00e1s all\u00e1 de eso y, por lo tanto, ocurre despu\u00e9s.\\n\\nSolucione esto cambiando la comprobaci\u00f3n de fin para que siempre sea el fin del folio y nunca el fin del archivo.\\n\\nEn el futuro, deber\u00eda considerar borrar hasta el final del folio aqu\u00ed en lugar de a\u00f1adir una subpetici\u00f3n ZERO para hacer esto. Por otro lado, la subpetici\u00f3n ZERO puede ejecutarse en paralelo con una subpetici\u00f3n READ as\u00edncrona. Adem\u00e1s, la subpetici\u00f3n ZERO a\u00fan puede ser necesaria para, por ejemplo, manejar extensiones en un archivo ceph que no tienen ning\u00fan almacenamiento de respaldo y, por lo tanto, son impl\u00edcitamente todo ceros.\\n\\nEsto se puede reproducir creando un archivo cuyo tama\u00f1o no se alinea con un l\u00edmite de p\u00e1gina, por ejemplo, 24998 (0x5fb2) bytes, y luego haciendo algo como:\\n\\n xfs_io -c \\\"mmap -r 0 0x6000\\\" -c \\\"madvise -d 0 0x6000\\\" \\\\\\n -c \\\"mread -v 0 0x6000\\\" /xfstest.test/x\\n\\nLos \u00faltimos 0x4e bytes deber\u00edan ser todos 00, pero si la cola no ha sido borrada todav\u00eda, es posible que vea basura all\u00ed. Esto se puede reproducir con kafs modificando el kernel para deshabilitar la llamada a netfs_read_subreq_progress() y para evitar que afs_issue_read() realice la llamada as\u00edncrona para NETFS_READAHEAD. La reproducci\u00f3n se puede facilitar insertando un mdelay(100) en netfs_issue_read() para el caso de la subpetici\u00f3n ZERO.\\n\\nAFS y CIFS normalmente no suelen mostrar esto, ya que despachan operaciones READ de forma as\u00edncrona, lo que permite que la subpetici\u00f3n ZERO termine primero. La operaci\u00f3n READ de 9P es completamente s\u00edncrona, por lo que la subpetici\u00f3n ZERO siempre ocurrir\u00e1 despu\u00e9s. Sin embargo, no se ve todo el tiempo, porque la recopilaci\u00f3n puede realizarse en un hilo de trabajo.\"}],\"metrics\":{},\"references\":[{\"url\":\"https://git.kernel.org/stable/c/570ad253a3455a520f03c2136af8714bc780186d\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/5b5482c0e5ee740b35a70759d3582477aea8e8e4\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"}]}}"
}
}