CVE-2025-38492

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfs: Fix race between cache write completion and ALL_QUEUED being set<br /> <br /> When netfslib is issuing subrequests, the subrequests start processing<br /> immediately and may complete before we reach the end of the issuing<br /> function. At the end of the issuing function we set NETFS_RREQ_ALL_QUEUED<br /> to indicate to the collector that we aren&amp;#39;t going to issue any more subreqs<br /> and that it can do the final notifications and cleanup.<br /> <br /> Now, this isn&amp;#39;t a problem if the request is synchronous<br /> (NETFS_RREQ_OFFLOAD_COLLECTION is unset) as the result collection will be<br /> done in-thread and we&amp;#39;re guaranteed an opportunity to run the collector.<br /> <br /> However, if the request is asynchronous, collection is primarily triggered<br /> by the termination of subrequests queuing it on a workqueue. Now, a race<br /> can occur here if the app thread sets ALL_QUEUED after the last subrequest<br /> terminates.<br /> <br /> This can happen most easily with the copy2cache code (as used by Ceph)<br /> where, in the collection routine of a read request, an asynchronous write<br /> request is spawned to copy data to the cache. Folios are added to the<br /> write request as they&amp;#39;re unlocked, but there may be a delay before<br /> ALL_QUEUED is set as the write subrequests may complete before we get<br /> there.<br /> <br /> If all the write subreqs have finished by the ALL_QUEUED point, no further<br /> events happen and the collection never happens, leaving the request<br /> hanging.<br /> <br /> Fix this by queuing the collector after setting ALL_QUEUED. This is a bit<br /> heavy-handed and it may be sufficient to do it only if there are no extant<br /> subreqs.<br /> <br /> Also add a tracepoint to cross-reference both requests in a copy-to-request<br /> operation and add a trace to the netfs_rreq tracepoint to indicate the<br /> setting of ALL_QUEUED.