CVE-2025-38338

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/nfs/read: fix double-unlock bug in nfs_return_empty_folio()<br /> <br /> Sometimes, when a file was read while it was being truncated by<br /> another NFS client, the kernel could deadlock because folio_unlock()<br /> was called twice, and the second call would XOR back the `PG_locked`<br /> flag.<br /> <br /> Most of the time (depending on the timing of the truncation), nobody<br /> notices the problem because folio_unlock() gets called three times,<br /> which flips `PG_locked` back off:<br /> <br /> 1. vfs_read, nfs_read_folio, ... nfs_read_add_folio,<br /> nfs_return_empty_folio<br /> 2. vfs_read, nfs_read_folio, ... netfs_read_collection,<br /> netfs_unlock_abandoned_read_pages<br /> 3. vfs_read, ... nfs_do_read_folio, nfs_read_add_folio,<br /> nfs_return_empty_folio<br /> <br /> The problem is that nfs_read_add_folio() is not supposed to unlock the<br /> folio if fscache is enabled, and a nfs_netfs_folio_unlock() check is<br /> missing in nfs_return_empty_folio().<br /> <br /> Rarely this leads to a warning in netfs_read_collection():<br /> <br /> ------------[ cut here ]------------<br /> R=0000031c: folio 10 is not locked<br /> WARNING: CPU: 0 PID: 29 at fs/netfs/read_collect.c:133 netfs_read_collection+0x7c0/0xf00<br /> [...]<br /> Workqueue: events_unbound netfs_read_collection_worker<br /> RIP: 0010:netfs_read_collection+0x7c0/0xf00<br /> [...]<br /> Call Trace:<br /> <br /> netfs_read_collection_worker+0x67/0x80<br /> process_one_work+0x12e/0x2c0<br /> worker_thread+0x295/0x3a0<br /> <br /> Most of the time, however, processes just get stuck forever in<br /> folio_wait_bit_common(), waiting for `PG_locked` to disappear, which<br /> never happens because nobody is really holding the folio lock.