Linux: Double Free
CVE-2025-38338 is a high-severity double free vulnerability in Linux, with a CVSS 3.1 base score of 7.8 out of 10. It can be exploited with local access to the system by an attacker with a low-privileged account, without any action from a user. The record lists versions 14f5549ad163be2c018abc1bb38370fff617a243, 5bf0b9eeb0174686f22c2e5b8fb9f47ad25da6f5, 1e93b61d3eaa14bfebcc2716ac09d43f3845d420 as the first without the flaw, so updating Linux to one of those releases or later removes the exposure. There is no confirmed exploitation so far. EPSS estimates a 0.19% chance of exploitation within 30 days, which is low compared with other CVEs.
High severity with no evidence of exploitation so far.
What to do
- Update Linux to 14f5549ad163be2c018abc1bb38370fff617a243 or 5bf0b9eeb0174686f22c2e5b8fb9f47ad25da6f5 or 1e93b61d3eaa14bfebcc2716ac09d43f3845d420 or 4c10fa44bc5f700e2ea21de2fbae520ba21f19d9, whichever matches your release line, or a later version.
- Update Linux Kernel to 6.6.95 or 6.12.35 or 6.15.4, whichever matches your release line, or a later version.
Affected products and versions
| Vendor | Product | Affected versions | Fixed in |
|---|---|---|---|
| Linux | Linux | 000dbe0bec058cbf2ca9e156e4a5584f5158b0f9 up to, but not including, 14f5549ad163be2c018abc1bb38370fff617a243; 000dbe0bec058cbf2ca9e156e4a5584f5158b0f9 up to, but not including, 5bf0b9eeb0174686f22c2e5b8fb9f47ad25da6f5; 000dbe0bec058cbf2ca9e156e4a5584f5158b0f9 up to, but not including, 1e93b61d3eaa14bfebcc2716ac09d43f3845d420; 000dbe0bec058cbf2ca9e156e4a5584f5158b0f9 up to, but not including, 4c10fa44bc5f700e2ea21de2fbae520ba21f19d9; 6.4 | 14f5549ad163be2c018abc1bb38370fff617a243, 5bf0b9eeb0174686f22c2e5b8fb9f47ad25da6f5, 1e93b61d3eaa14bfebcc2716ac09d43f3845d420, 4c10fa44bc5f700e2ea21de2fbae520ba21f19d9 |
| Linux | Linux Kernel | 6.4 up to, but not including, 6.6.95; 6.7 up to, but not including, 6.12.35; 6.13 up to, but not including, 6.15.4 | 6.6.95, 6.12.35, 6.15.4 |
Version data comes from the organisation that assigned the CVE. Confirm against the vendor advisory before deciding you are unaffected.
How the severity score breaks down
- Attack vector
- LocalThe attacker needs local access or must trick a user into running something.
- Attack complexity
- LowNo special conditions are needed; the attack works reliably.
- Privileges required
- LowA basic user account is enough.
- User interaction
- NoneNo action by a victim is required.
- Scope
- UnchangedImpact stays within the vulnerable component.
- Confidentiality
- HighAll data handled by the component can be read.
- Integrity
- HighData or code can be modified at will.
- Availability
- HighThe component can be taken down completely.
Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H. Scored by NVD.
Official description
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.
Source: the CVE record as published by its numbering authority, via NVD and CVE.org.
The underlying weakness: Double Free
The product calls free() twice on the same memory address.
How developers prevent this class of flaw
- Choose a language that provides automatic memory management.
- Ensure that each allocation is freed only once. After freeing a chunk, set the pointer to NULL to ensure the pointer cannot be freed again. In complicated error conditions, be sure that clean-up routines respect the state of allocation properly. If the language is object oriented, ensure that object destructors delete each chunk of memory only once.
- Use a static analysis tool to find double free instances.
Timeline
- CVE record published.
- CISA published its SSVC assessment (exploitation: none, automatable: no, technical impact: partial).
- Record last changed materially (score, affected products, status or references).
References
Patches and release notes
Recent Double Free vulnerabilities
- 7.8 High severity
- 7.8 High severity
- 8.2 High severity
- 7.8 High severity
- 7.8 High severity
- 7.8 High severity
Spotted an error? Tell us.