{ "dataType": "CVE_RECORD", "dataVersion": "5.2", "cveMetadata": { "cveId": "CVE-2025-71201", "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "state": "PUBLISHED", "assignerShortName": "Linux", "dateReserved": "2026-01-31T11:36:51.193Z", "datePublished": "2026-02-14T15:22:21.233Z", "dateUpdated": "2026-08-05T12:12:30.514Z" }, "containers": { "cna": { "providerMetadata": { "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "shortName": "Linux", "dateUpdated": "2026-08-05T12:12:30.514Z" }, "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 'cto=5fb2' indicates the collected file pos we've collected results to\nso far - but we still have 0x4e more bytes to go - so we shouldn't have\ncollected folio ix=00005 yet. The 'ZERO' 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't have any\nbacking store and are thus implicitly all zeros.\n\nThis can be reproduced by creating a file, the size of which doesn't 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't 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's READ op is\ncompletely synchronous, so the ZERO-subreq will always happen after. It isn't\nseen all the time, though, because the collection may be done in a worker\nthread." } ], "metrics": [ { "cvssV3_1": { "version": "3.1", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H", "baseScore": 7.1, "baseSeverity": "HIGH" }, "scenarios": [ { "lang": "en", "value": "AV:L - Exploitation requires a local process to mmap and fault the post-EOF portion of a file on an affected netfs mount; remote filesystem responses alone do not disclose the stale bytes to the remote peer.\nAC:L - An attacker can choose an unaligned file, evict its clean EOF folio, and repeatedly trigger concurrent readahead faults; 9P also deterministically completes the synchronous READ before issuing the zero-fill.\nPR:L - An ordinary unprivileged user with read access to a file on an existing affected mount can reach the flaw without capabilities or administrative privileges.\nUI:N - The attacker performs the mmap, cache eviction, and memory accesses directly, requiring no action by another user.\nS:U - The disclosure and resulting disruption occur within the same host kernel and its userspace security authority, without crossing a VM, IOMMU, or other scope boundary.\nC:H - The prematurely exposed folio tail can contain stale page-allocator data, potentially revealing sensitive kernel, page-cache, or prior-process contents; repeated eviction and refaulting can yield additional samples.\nI:N - The flaw exposes uncleared bytes but provides no attacker-controlled write, persistent file modification, or kernel-memory corruption primitive.\nA:H - The prematurely published uptodate folio can repeatedly provide corrupted post-EOF contents to mmap consumers, and in a critical mmap-dependent service this can cause processing failure or a crash." } ] } ], "affected": [ { "product": "Linux", "vendor": "Linux", "defaultStatus": "unaffected", "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "programFiles": [ "fs/netfs/read_collect.c" ], "versions": [ { "version": "e2d46f2ec332533816417b60933954173f602121", "lessThan": "5b5482c0e5ee740b35a70759d3582477aea8e8e4", "status": "affected", "versionType": "git" }, { "version": "e2d46f2ec332533816417b60933954173f602121", "lessThan": "570ad253a3455a520f03c2136af8714bc780186d", "status": "affected", "versionType": "git" } ] }, { "product": "Linux", "vendor": "Linux", "defaultStatus": "affected", "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "programFiles": [ "fs/netfs/read_collect.c" ], "versions": [ { "version": "6.14", "status": "affected" }, { "version": "0", "lessThan": "6.14", "status": "unaffected", "versionType": "semver" }, { "version": "6.18.6", "lessThanOrEqual": "6.18.*", "status": "unaffected", "versionType": "semver" }, { "version": "6.19", "lessThanOrEqual": "*", "status": "unaffected", "versionType": "original_commit_for_fix" } ] } ], "cpeApplicability": [ { "nodes": [ { "operator": "OR", "negate": false, "cpeMatch": [ { "vulnerable": true, "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "versionStartIncluding": "6.14", "versionEndExcluding": "6.18.6" }, { "vulnerable": true, "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "versionStartIncluding": "6.14", "versionEndExcluding": "6.19" } ] } ] } ], "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" } } } }