Wind River Support Network

Description

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

CREATE(Triage):(User=admin) [CVE-2025-38338 (https://nvd.nist.gov/vuln/detail/CVE-2025-38338)