CVE-2025-38524

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rxrpc: Fix recv-recv race of completed call<br /> <br /> If a call receives an event (such as incoming data), the call gets placed<br /> on the socket&amp;#39;s queue and a thread in recvmsg can be awakened to go and<br /> process it. Once the thread has picked up the call off of the queue,<br /> further events will cause it to be requeued, and once the socket lock is<br /> dropped (recvmsg uses call-&gt;user_mutex to allow the socket to be used in<br /> parallel), a second thread can come in and its recvmsg can pop the call off<br /> the socket queue again.<br /> <br /> In such a case, the first thread will be receiving stuff from the call and<br /> the second thread will be blocked on call-&gt;user_mutex. The first thread<br /> can, at this point, process both the event that it picked call for and the<br /> event that the second thread picked the call for and may see the call<br /> terminate - in which case the call will be "released", decoupling the call<br /> from the user call ID assigned to it (RXRPC_USER_CALL_ID in the control<br /> message).<br /> <br /> The first thread will return okay, but then the second thread will wake up<br /> holding the user_mutex and, if it sees that the call has been released by<br /> the first thread, it will BUG thusly:<br /> <br /> kernel BUG at net/rxrpc/recvmsg.c:474!<br /> <br /> Fix this by just dequeuing the call and ignoring it if it is seen to be<br /> already released. We can&amp;#39;t tell userspace about it anyway as the user call<br /> ID has become stale.