CVE-2025-38338

In the Linux kernel, the following vulnerability has been resolved:

fs/nfs/read: fix double-unlock bug in nfsreturnempty_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. vfsread, nfsreadfolio, ... nfsreadaddfolio, nfsreturnempty_folio
2. vfsread, nfsreadfolio, ... netfsreadcollection, netfsunlockabandonedread_pages
3. vfsread, ... nfsdoreadfolio, nfsreadaddfolio, nfsreturnemptyfolio

The problem is that nfsreadaddfolio() is not supposed to unlock the folio if fscache is enabled, and a nfsnetfsfoliounlock() check is missing in nfsreturnempty_folio().

Rarely this leads to a warning in netfsreadcollection():

------------[ cut here ]------------ R=0000031c: folio 10 is not locked WARNING: CPU: 0 PID: 29 at fs/netfs/readcollect.c:133 netfsreadcollection+0x7c0/0xf00 [...] Workqueue: eventsunbound netfsreadcollectionworker RIP: 0010:netfsreadcollection+0x7c0/0xf00 [...] Call Trace: <TASK> netfsreadcollectionworker+0x67/0x80 processonework+0x12e/0x2c0 worker_thread+0x295/0x3a0

Most of the time, however, processes just get stuck forever in foliowaitbit_common(), waiting for PG_locked to disappear, which never happens because nobody is really holding the folio lock.