CVE-2025-38338 Information

Jul 12, 2025 cve

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: 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.

Reference

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

CNNVD-202507-1464 (Published: 2025-07-10)

Share on: