fs/nfs/read: fix double-unlock bug in nfs_return_empty_folio()
In the Linux kernel, the following vulnerability has been resolved: fs/nfs/read: fix double-unlock bug in nfs_return_empty_folio() Sometimes, when a file was read while it was being truncated by another NFS client, the kernel could deadlock because folio_unlock() was called twice, and the second call would XOR back the `PG_locked` flag. Most of the time (depending on the timing of the truncation), nobody notices the problem because folio_unlock() gets called three times, which flips `PG_locked` back off: 1. vfs_read, nfs_read_folio, ... nfs_read_add_folio, nfs_return_empty_folio 2. vfs_read, nfs_read_folio, ... netfs_read_collection, netfs_unlock_abandoned_read_pages 3. vfs_read, ... nfs_do_read_folio, nfs_read_add_folio, nfs_return_empty_folio The problem is that nfs_read_add_folio() is not supposed to unlock the folio if fscache is enabled, and a nfs_netfs_folio_unlock() check is missing in nfs_return_empty_folio(). Rarely this leads to a warning in netfs_read_collection(): ------------[ cut here ]------------ R=0000031c: folio 10 is not locked WARNING: CPU: 0 PID: 29 at fs/netfs/read_collect.c:133 netfs_read_collection+0x7c0/0xf00 [...] Workqueue: events_unbound netfs_read_collection_worker RIP: 0010:netfs_read_collection+0x7c0/0xf00 [...] Call Trace: netfs_read_collection_worker+0x67/0x80 process_one_work+0x12e/0x2c0 worker_thread+0x295/0x3a0 Most of the time, however, processes just get stuck forever in folio_wait_bit_common(), waiting for `PG_locked` to disappear, which
- Products
- Kernel
- Affected versions
- Not specified
- Fixed versions
- 6.12.35, 6.15.4, 6.6.95
- CVEs
- CVE-2025-38338
- Confirmed fixed CVEs
- Not specified
- Updated in this feed
- 4 Nov 2026, 16:15 UTC · Revision 1
Source evidence
fs/nfs/read: fix double-unlock bug in nfs_return_empty_folio()
core-osv · Original sourcePublished 10 Jul 2025, 08:15 UTC
In the Linux kernel, the following vulnerability has been resolved: fs/nfs/read: fix double-unlock bug in nfs_return_empty_folio() Sometimes, when a file was read while it was being truncated by another NFS client, the kernel could deadlock because folio_unlock() was called twice, and the second call would XOR back the `PG_locked` flag. Most of the time (depending on the timing of the truncation), nobody notices the problem because folio_unlock() gets called three times, which flips `PG_locked` back off: 1. vfs_read, nfs_read_folio, ... nfs_read_add_folio, nfs_return_empty_folio 2. vfs_read, nfs_read_folio, ... netfs_read_collection, netfs_unlock_abandoned_read_pages 3. vfs_read, ... nfs_do_read_folio, nfs_read_add_folio, nfs_return_empty_folio The problem is that nfs_read_add_folio() is not supposed to unlock the folio if fscache is enabled, and a nfs_netfs_folio_unlock() check is missing in nfs_return_empty_folio(). Rarely this leads to a warning in netfs_read_collection(): ------------[ cut here ]------------ R=0000031c: folio 10 is not locked WARNING: CPU: 0 PID: 29 at fs/netfs/read_collect.c:133 netfs_read_collection+0x7c0/0xf00 [...] Workqueue: events_unbound netfs_read_collection_worker RIP: 0010:netfs_read_collection+0x7c0/0xf00 [...] Call Trace: netfs_read_collection_worker+0x67/0x80 process_one_work+0x12e/0x2c0 worker_thread+0x295/0x3a0 Most of the time, however, processes just get stuck forever in folio_wait_bit_common(), waiting for `PG_locked` to disappear, which
osv:CVE-2025-38338
Kernel
Fixed versions: 6.6.95, 6.12.35, 6.15.4
Complete source record
{
"id": "eed860bc73f39669e376f55683e288d7ab508064eb1e9eadaed3a143ee8e06b5",
"url": "https://osv.dev/vulnerability/CVE-2025-38338",
"method": "structured",
"payload": {
"kind": "advisory",
"title": "fs/nfs/read: fix double-unlock bug in nfs_return_empty_folio()",
"summary": "In the Linux kernel, the following vulnerability has been resolved: fs/nfs/read: fix double-unlock bug in nfs_return_empty_folio() Sometimes, when a file was read while it was being truncated by another NFS client, the kernel could deadlock because folio_unlock() was called twice, and the second call would XOR back the `PG_locked` flag. Most of the time (depending on the timing of the truncation), nobody notices the problem because folio_unlock() gets called three times, which flips `PG_locked` back off: 1. vfs_read, nfs_read_folio, ... nfs_read_add_folio, nfs_return_empty_folio 2. vfs_read, nfs_read_folio, ... netfs_read_collection, netfs_unlock_abandoned_read_pages 3. vfs_read, ... nfs_do_read_folio, nfs_read_add_folio, nfs_return_empty_folio The problem is that nfs_read_add_folio() is not supposed to unlock the folio if fscache is enabled, and a nfs_netfs_folio_unlock() check is missing in nfs_return_empty_folio(). Rarely this leads to a warning in netfs_read_collection(): ------------[ cut here ]------------ R=0000031c: folio 10 is not locked WARNING: CPU: 0 PID: 29 at fs/netfs/read_collect.c:133 netfs_read_collection+0x7c0/0xf00 [...] Workqueue: events_unbound netfs_read_collection_worker RIP: 0010:netfs_read_collection+0x7c0/0xf00 [...] Call Trace: netfs_read_collection_worker+0x67/0x80 process_one_work+0x12e/0x2c0 worker_thread+0x295/0x3a0 Most of the time, however, processes just get stuck forever in folio_wait_bit_common(), waiting for `PG_locked` to disappear, which",
"evidence": "osv:CVE-2025-38338",
"products": [
{
"name": {
"value": "Kernel",
"evidence": "/affected/1/package/name"
},
"prerequisites": [],
"fixed_versions": [
{
"value": "6.6.95",
"evidence": "/affected/1/ranges"
},
{
"value": "6.12.35",
"evidence": "/affected/1/ranges"
},
{
"value": "6.15.4",
"evidence": "/affected/1/ranges"
}
],
"affected_versions": []
}
],
"severity": "unknown",
"structured": {
"id": "CVE-2025-38338",
"aliases": [
"CVE-2025-38338"
],
"affected": [
{
"ranges": [
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "000dbe0bec058cbf2ca9e156e4a5584f5158b0f9"
},
{
"fixed": "14f5549ad163be2c018abc1bb38370fff617a243"
},
{
"fixed": "5bf0b9eeb0174686f22c2e5b8fb9f47ad25da6f5"
},
{
"fixed": "1e93b61d3eaa14bfebcc2716ac09d43f3845d420"
},
{
"fixed": "4c10fa44bc5f700e2ea21de2fbae520ba21f19d9"
}
]
}
],
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2025-38338.json"
}
},
{
"ranges": [
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.4.0"
},
{
"fixed": "6.6.95"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.7.0"
},
{
"fixed": "6.12.35"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.13.0"
},
{
"fixed": "6.15.4"
}
]
}
],
"package": {
"name": "Kernel",
"ecosystem": "Linux"
},
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2025-38338.json"
}
}
],
"modified": "2026-10-28T02:30:37.486929478Z",
"provider": "osv",
"references": [
"https://git.kernel.org/stable/c/14f5549ad163be2c018abc1bb38370fff617a243",
"https://git.kernel.org/stable/c/1e93b61d3eaa14bfebcc2716ac09d43f3845d420",
"https://git.kernel.org/stable/c/4c10fa44bc5f700e2ea21de2fbae520ba21f19d9",
"https://git.kernel.org/stable/c/5bf0b9eeb0174686f22c2e5b8fb9f47ad25da6f5",
"https://github.com/CVEProject/cvelistV5/tree/main/cves/2025/38xxx/CVE-2025-38338.json",
"https://nvd.nist.gov/vuln/detail/CVE-2025-38338",
"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git"
],
"provider_metadata": {
"cna_assigner": "Linux",
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2025/38xxx/CVE-2025-38338.json"
}
},
"related_cves": [
{
"value": "CVE-2025-38338",
"evidence": "/id"
}
],
"security_relevant": true,
"severity_evidence": null
},
"source_id": "core-osv",
"document_id": 504563,
"published_at": "2025-07-10T08:15:09.022+00:00"
}