CVE-2025-38338
Unknown Unknown - Not Provided
BaseFortify

Publication date: 2025-07-10

Last updated on: 2025-11-18

Assigner: kernel.org

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.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2025-07-10
Last Modified
2025-11-18
Generated
2026-05-07
AI Q&A
2025-07-10
EPSS Evaluated
2026-05-05
NVD
Affected Vendors & Products
Showing 3 associated CPEs
Vendor Product Version / Range
linux linux_kernel From 5.15.160 (inc) to 5.16 (inc)
linux linux_kernel From 5.15.160 (inc) to 5.16 (inc)
linux linux_kernel From 5.15.160 (inc) to 5.16 (inc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-415 The product calls free() twice on the same memory address.
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability is a double-unlock bug in the Linux kernel's NFS file reading code. When a file is read while being truncated by another NFS client, the kernel may deadlock because a function called folio_unlock() is called twice on the same memory folio. This causes the kernel to wait indefinitely for a lock that is never properly held, leading to processes getting stuck or warnings being triggered.


How can this vulnerability impact me? :

The vulnerability can cause processes that read files over NFS to deadlock or hang indefinitely, potentially leading to system instability or degraded performance. In some cases, kernel warnings may be logged. This can disrupt normal file operations and affect system reliability when using NFS with concurrent file truncation.


How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability may be detected by observing kernel warnings related to folio locking issues, specifically warnings from netfs_read_collection such as: "WARNING: CPU: ... folio ... is not locked". Additionally, processes stuck indefinitely in folio_wait_bit_common() waiting for PG_locked to clear may indicate the issue. Monitoring kernel logs (e.g., using 'dmesg' or 'journalctl -k') for such warnings can help detect the problem. Specific commands include: 'dmesg | grep netfs_read_collection' or 'journalctl -k | grep folio'.


What immediate steps should I take to mitigate this vulnerability?

Immediate mitigation involves updating the Linux kernel to a version where the double-unlock bug in nfs_return_empty_folio() has been fixed. Since the issue arises from improper folio unlocking during NFS reads with fscache enabled, applying the patch that adds the missing nfs_netfs_folio_unlock() check in nfs_return_empty_folio() will resolve the deadlock and warning issues.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart