CVE-2025-38524 in Linux
Summary
by MITRE • 08/16/2025
In the Linux kernel, the following vulnerability has been resolved:
rxrpc: Fix recv-recv race of completed call
If a call receives an event (such as incoming data), the call gets placed on the socket's queue and a thread in recvmsg can be awakened to go and process it. Once the thread has picked up the call off of the queue, further events will cause it to be requeued, and once the socket lock is dropped (recvmsg uses call->user_mutex to allow the socket to be used in parallel), a second thread can come in and its recvmsg can pop the call off the socket queue again.
In such a case, the first thread will be receiving stuff from the call and the second thread will be blocked on call->user_mutex. The first thread can, at this point, process both the event that it picked call for and the event that the second thread picked the call for and may see the call terminate - in which case the call will be "released", decoupling the call from the user call ID assigned to it (RXRPC_USER_CALL_ID in the control message).
The first thread will return okay, but then the second thread will wake up holding the user_mutex and, if it sees that the call has been released by the first thread, it will BUG thusly:
kernel BUG at net/rxrpc/recvmsg.c:474!
Fix this by just dequeuing the call and ignoring it if it is seen to be already released. We can't tell userspace about it anyway as the user call ID has become stale.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 08/01/2026
The vulnerability CVE-2025-38524 resides within the Linux kernel's rxrpc subsystem, specifically addressing a race condition that occurs during the processing of completed network calls. This issue manifests when multiple threads attempt to handle the same network call simultaneously, creating a scenario where the call's state becomes inconsistent between thread execution contexts. The rxrpc protocol implementation manages asynchronous remote procedure calls over the network, and this particular flaw affects how the kernel handles the queuing and processing of incoming events for these calls. The vulnerability is classified under CWE-362, which represents a race condition where multiple threads access shared resources without proper synchronization mechanisms.
The technical flaw stems from the improper handling of call objects within the socket queue mechanism during concurrent recvmsg operations. When a network event arrives, the system places the call on a socket queue to be processed by a receiving thread. However, due to the lack of proper synchronization during the transition from queue processing to mutex acquisition, a second thread can potentially dequeue the same call after the first thread has already begun processing it. This race condition creates a scenario where the first thread processes events for a call that has already been released by the system, leading to a situation where the call object is no longer valid for the second thread's operations. The kernel's internal consistency checks detect this invalid state and trigger a kernel BUG, which is a critical system failure that terminates the kernel execution.
The operational impact of this vulnerability is severe as it can lead to kernel panics and system crashes when the race condition is triggered. This occurs because the kernel's recvmsg implementation does not properly validate whether a call has been released before attempting to process it, resulting in a direct reference to freed memory or invalid kernel data structures. The vulnerability affects any system running the Linux kernel with rxrpc functionality enabled, particularly those that handle high volumes of concurrent network calls or applications that utilize remote procedure call mechanisms. The attack vector requires concurrent access patterns to the same network call, making it potentially exploitable in multi-threaded applications or systems under heavy network load, though the specific conditions for triggering the race make it less likely to be exploited in all scenarios.
The fix implemented addresses the core synchronization issue by modifying the call processing logic to properly handle already-released calls during the dequeue operation. Instead of attempting to process a call that has already been released, the system now simply removes the call from the queue and ignores it if it detects that the call has been terminated by another thread. This approach aligns with the principle of defensive programming and prevents the kernel from accessing invalid memory structures that would otherwise cause the system to crash. The solution ensures that even if multiple threads attempt to process the same call, the system will gracefully handle the race condition by recognizing that the call is no longer valid for processing. This fix prevents the kernel BUG that occurs at net/rxrpc/recvmsg.c:474 and maintains system stability while preserving the integrity of the network call processing pipeline. The mitigation strategy follows established kernel security practices for handling concurrent access patterns and demonstrates proper resource management in multi-threaded kernel subsystems.