CVE-2025-38338 (GCVE-0-2025-38338)
Vulnerability from cvelistv5 – Published: 2025-07-10 08:15 – Updated: 2026-05-11 21:26
VLAI
EPSS
VEX
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:
<TASK>
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
never happens because nobody is really holding the folio lock.
Severity
7.8 (High)
Assigner
References
Impacted products
2 products
| Vendor | Product | Version | CPE status | |
|---|---|---|---|---|
| Linux | Linux |
Affected:
000dbe0bec058cbf2ca9e156e4a5584f5158b0f9 , < 14f5549ad163be2c018abc1bb38370fff617a243
(git)
Affected: 000dbe0bec058cbf2ca9e156e4a5584f5158b0f9 , < 5bf0b9eeb0174686f22c2e5b8fb9f47ad25da6f5 (git) Affected: 000dbe0bec058cbf2ca9e156e4a5584f5158b0f9 , < 1e93b61d3eaa14bfebcc2716ac09d43f3845d420 (git) Affected: 000dbe0bec058cbf2ca9e156e4a5584f5158b0f9 , < 4c10fa44bc5f700e2ea21de2fbae520ba21f19d9 (git) |
guessed | |
| Linux | Linux |
Affected:
6.4
Unaffected: 0 , < 6.4 (semver) Unaffected: 6.6.95 , ≤ 6.6.* (semver) Unaffected: 6.12.35 , ≤ 6.12.* (semver) Unaffected: 6.15.4 , ≤ 6.15.* (semver) Unaffected: 6.16 , ≤ * (original_commit_for_fix) |
guessed |
{
"containers": {
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"fs/nfs/read.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "14f5549ad163be2c018abc1bb38370fff617a243",
"status": "affected",
"version": "000dbe0bec058cbf2ca9e156e4a5584f5158b0f9",
"versionType": "git"
},
{
"lessThan": "5bf0b9eeb0174686f22c2e5b8fb9f47ad25da6f5",
"status": "affected",
"version": "000dbe0bec058cbf2ca9e156e4a5584f5158b0f9",
"versionType": "git"
},
{
"lessThan": "1e93b61d3eaa14bfebcc2716ac09d43f3845d420",
"status": "affected",
"version": "000dbe0bec058cbf2ca9e156e4a5584f5158b0f9",
"versionType": "git"
},
{
"lessThan": "4c10fa44bc5f700e2ea21de2fbae520ba21f19d9",
"status": "affected",
"version": "000dbe0bec058cbf2ca9e156e4a5584f5158b0f9",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"fs/nfs/read.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "6.4"
},
{
"lessThan": "6.4",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.95",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.35",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.15.*",
"status": "unaffected",
"version": "6.15.4",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.16",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.6.95",
"versionStartIncluding": "6.4",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.12.35",
"versionStartIncluding": "6.4",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.15.4",
"versionStartIncluding": "6.4",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.16",
"versionStartIncluding": "6.4",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nfs/nfs/read: fix double-unlock bug in nfs_return_empty_folio()\n\nSometimes, when a file was read while it was being truncated by\nanother NFS client, the kernel could deadlock because folio_unlock()\nwas called twice, and the second call would XOR back the `PG_locked`\nflag.\n\nMost of the time (depending on the timing of the truncation), nobody\nnotices the problem because folio_unlock() gets called three times,\nwhich flips `PG_locked` back off:\n\n 1. vfs_read, nfs_read_folio, ... nfs_read_add_folio,\n nfs_return_empty_folio\n 2. vfs_read, nfs_read_folio, ... netfs_read_collection,\n netfs_unlock_abandoned_read_pages\n 3. vfs_read, ... nfs_do_read_folio, nfs_read_add_folio,\n nfs_return_empty_folio\n\nThe problem is that nfs_read_add_folio() is not supposed to unlock the\nfolio if fscache is enabled, and a nfs_netfs_folio_unlock() check is\nmissing in nfs_return_empty_folio().\n\nRarely this leads to a warning in netfs_read_collection():\n\n ------------[ cut here ]------------\n R=0000031c: folio 10 is not locked\n WARNING: CPU: 0 PID: 29 at fs/netfs/read_collect.c:133 netfs_read_collection+0x7c0/0xf00\n [...]\n Workqueue: events_unbound netfs_read_collection_worker\n RIP: 0010:netfs_read_collection+0x7c0/0xf00\n [...]\n Call Trace:\n \u003cTASK\u003e\n netfs_read_collection_worker+0x67/0x80\n process_one_work+0x12e/0x2c0\n worker_thread+0x295/0x3a0\n\nMost of the time, however, processes just get stuck forever in\nfolio_wait_bit_common(), waiting for `PG_locked` to disappear, which\nnever happens because nobody is really holding the folio lock."
}
],
"providerMetadata": {
"dateUpdated": "2026-05-11T21:26:03.883Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/14f5549ad163be2c018abc1bb38370fff617a243"
},
{
"url": "https://git.kernel.org/stable/c/5bf0b9eeb0174686f22c2e5b8fb9f47ad25da6f5"
},
{
"url": "https://git.kernel.org/stable/c/1e93b61d3eaa14bfebcc2716ac09d43f3845d420"
},
{
"url": "https://git.kernel.org/stable/c/4c10fa44bc5f700e2ea21de2fbae520ba21f19d9"
}
],
"title": "fs/nfs/read: fix double-unlock bug in nfs_return_empty_folio()",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2025-38338",
"datePublished": "2025-07-10T08:15:09.022Z",
"dateReserved": "2025-04-16T04:51:24.005Z",
"dateUpdated": "2026-05-11T21:26:03.883Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2",
"vulnerability-lookup:meta": {
"epss": {
"cve": "CVE-2025-38338",
"date": "2026-10-30",
"epss": "0.00185",
"percentile": "0.08134"
},
"microsoft_vex": {
"current_release_date": "2026-02-18T14:59:45.000Z",
"cve": "CVE-2025-38338",
"id": "msrc_CVE-2025-38338",
"initial_release_date": "2025-07-02T00:00:00.000Z",
"product_status:fixed": "2",
"product_status:known_affected": "2",
"source": "Microsoft CSAF VEX",
"status": "final",
"title": "fs/nfs/read: fix double-unlock bug in nfs_return_empty_folio()",
"url": "https://msrc.microsoft.com/csaf/vex/2025/msrc_cve-2025-38338.json",
"version": "2"
},
"nvd": {
"cve": {
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"fs/nfs/read.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "14f5549ad163be2c018abc1bb38370fff617a243",
"status": "affected",
"version": "000dbe0bec058cbf2ca9e156e4a5584f5158b0f9",
"versionType": "git"
},
{
"lessThan": "5bf0b9eeb0174686f22c2e5b8fb9f47ad25da6f5",
"status": "affected",
"version": "000dbe0bec058cbf2ca9e156e4a5584f5158b0f9",
"versionType": "git"
},
{
"lessThan": "1e93b61d3eaa14bfebcc2716ac09d43f3845d420",
"status": "affected",
"version": "000dbe0bec058cbf2ca9e156e4a5584f5158b0f9",
"versionType": "git"
},
{
"lessThan": "4c10fa44bc5f700e2ea21de2fbae520ba21f19d9",
"status": "affected",
"version": "000dbe0bec058cbf2ca9e156e4a5584f5158b0f9",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"fs/nfs/read.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "6.4"
},
{
"lessThan": "6.4",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.95",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.35",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.15.*",
"status": "unaffected",
"version": "6.15.4",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.16",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"configurations": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "F17A70D5-5B72-4411-9C16-98EF57D0C931",
"versionEndExcluding": "6.6.95",
"versionStartIncluding": "6.4",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "E569FD34-0076-4428-BE17-EECCF867611C",
"versionEndExcluding": "6.12.35",
"versionStartIncluding": "6.7",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "DFD174C5-1AA2-4671-BDDC-1A9FCC753655",
"versionEndExcluding": "6.15.4",
"versionStartIncluding": "6.13",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nfs/nfs/read: fix double-unlock bug in nfs_return_empty_folio()\n\nSometimes, when a file was read while it was being truncated by\nanother NFS client, the kernel could deadlock because folio_unlock()\nwas called twice, and the second call would XOR back the `PG_locked`\nflag.\n\nMost of the time (depending on the timing of the truncation), nobody\nnotices the problem because folio_unlock() gets called three times,\nwhich flips `PG_locked` back off:\n\n 1. vfs_read, nfs_read_folio, ... nfs_read_add_folio,\n nfs_return_empty_folio\n 2. vfs_read, nfs_read_folio, ... netfs_read_collection,\n netfs_unlock_abandoned_read_pages\n 3. vfs_read, ... nfs_do_read_folio, nfs_read_add_folio,\n nfs_return_empty_folio\n\nThe problem is that nfs_read_add_folio() is not supposed to unlock the\nfolio if fscache is enabled, and a nfs_netfs_folio_unlock() check is\nmissing in nfs_return_empty_folio().\n\nRarely this leads to a warning in netfs_read_collection():\n\n ------------[ cut here ]------------\n R=0000031c: folio 10 is not locked\n WARNING: CPU: 0 PID: 29 at fs/netfs/read_collect.c:133 netfs_read_collection+0x7c0/0xf00\n [...]\n Workqueue: events_unbound netfs_read_collection_worker\n RIP: 0010:netfs_read_collection+0x7c0/0xf00\n [...]\n Call Trace:\n \u003cTASK\u003e\n netfs_read_collection_worker+0x67/0x80\n process_one_work+0x12e/0x2c0\n worker_thread+0x295/0x3a0\n\nMost of the time, however, processes just get stuck forever in\nfolio_wait_bit_common(), waiting for `PG_locked` to disappear, which\nnever happens because nobody is really holding the folio lock."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fs/nfs/read: corrige error de doble desbloqueo en nfs_return_empty_folio() En ocasiones, cuando se le\u00eda un archivo mientras otro cliente NFS lo estaba truncando, el kernel pod\u00eda bloquearse porque se llamaba a folio_unlock() dos veces y la segunda llamada XOR devolver\u00eda el indicador `PG_locked`. La mayor\u00eda de las veces (dependiendo del momento del truncamiento), nadie nota el problema porque folio_unlock() se llama tres veces, lo que desactiva `PG_locked`: 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 El problema es que nfs_read_add_folio() no debe desbloquear el folio si fscache est\u00e1 habilitado, y falta una comprobaci\u00f3n nfs_netfs_folio_unlock() en nfs_return_empty_folio(). En raras ocasiones, esto genera una advertencia en netfs_read_collection(): ------------[ cortar aqu\u00ed ]------------ R=0000031c: el folio 10 no est\u00e1 bloqueado ADVERTENCIA: CPU: 0 PID: 29 en fs/netfs/read_collect.c:133 netfs_read_collection+0x7c0/0xf00 [...] Cola de trabajo: events_unbound netfs_read_collection_worker RIP: 0010:netfs_read_collection+0x7c0/0xf00 [...] Rastreo de llamadas: netfs_read_collection_worker+0x67/0x80 process_one_work+0x12e/0x2c0worker_thread+0x295/0x3a0 Sin embargo, la mayor\u00eda de las veces, los procesos simplemente se quedan atascados para siempre en folio_wait_bit_common(), esperando que `PG_locked` desaparezca, lo que nunca sucede porque nadie est\u00e1 realmente reteniendo el cerradura de folio. "
}
],
"id": "CVE-2025-38338",
"lastModified": "2026-06-17T09:16:39.273",
"metrics": {
"cvssMetricV31": [
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 7.8,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
},
"exploitabilityScore": 1.8,
"impactScore": 5.9,
"source": "nvd@nist.gov",
"type": "Primary"
}
]
},
"published": "2025-07-10T09:15:28.510",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/14f5549ad163be2c018abc1bb38370fff617a243"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/1e93b61d3eaa14bfebcc2716ac09d43f3845d420"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/4c10fa44bc5f700e2ea21de2fbae520ba21f19d9"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/5bf0b9eeb0174686f22c2e5b8fb9f47ad25da6f5"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Analyzed",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "CWE-415"
}
],
"source": "nvd@nist.gov",
"type": "Primary"
}
]
}
},
"redhat_vex": {
"aggregate_severity": "Moderate",
"current_release_date": "2026-06-30T01:04:24+00:00",
"cve": "CVE-2025-38338",
"id": "CVE-2025-38338",
"initial_release_date": "2025-07-10T00:00:00+00:00",
"product_status:known_affected": "198",
"product_status:known_not_affected": "76",
"source": "Red Hat CSAF VEX",
"status": "final",
"title": "kernel: fs/nfs/read: fix double-unlock bug in nfs_return_empty_folio()",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2025/cve-2025-38338.json",
"version": "3"
}
}
}
Loading…
Loading…
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
Experimental. This forecast is provided for visualization only and may change without notice. Do not use it for operational decisions.
Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
Loading timeline…
Loading…
Loading…
The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the
vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base
model, served locally by ML-Gateway.
They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Loading…
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.