Wind River Support Network

Description

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

CREATE(Triage):(User=pbi-cn) [CVE-2025-38524 (https://nvd.nist.gov/vuln/detail/CVE-2025-38524)