rxrpc: Fix recv-recv race of completed call
Affects Linux kernel rxrpc code from 4.9.0 up to the fixed releases 5.10.266, 6.6.100, 6.12.40 and 6.15.8, depending on branch. The fix is in those releases.
- Published
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- How many real-world setups can hit the bug, from the vendor's advisory and CISA data. It does not know your setup.What do these mean? →
- Unclear
- Fix
- Fixed in 5.10.266, 6.6.100, 6.12.40, 6.15.8
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
- Exploitation: none
- Automatable: yes
- Technical impact: partial
Summary
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.
Timeline
- CVE published
- CISA SSVC assessment
Exploitation: none · Automatable: yes · Technical impact: partial
- Record last updated
Affected versions
- Linux Linux
Version range not reported
- Linux Linux
4.9
- KernelLinux
From 4.9.0 · fixed in 5.10.266; From 5.11.0 · fixed in 6.6.100; From 6.7.0 · fixed in 6.12.40; From 6.13.0 · fixed in 6.15.8
References 6
git.kernel.org
Questions about CVE-2025-38524
What does this mean?
When a call receives an event while a second recvmsg thread waits on the call's user mutex, and the first thread finishes the call before the second proceeds, the kernel hits a BUG (crash) once the second thread finds the call already released.Source: git.kernel.org
Am I affected, and how do I check?
Kernels from 4.9.0 up to the fixed versions per branch are in scope: 5.10 before 5.10.266, 5.11 through 6.6 before 6.6.100, 6.7 through 6.12 before 6.12.40, and 6.13 through 6.15 before 6.15.8. Check the running version with uname -r. The bug needs two recvmsg threads racing on the same rxrpc call.Source: git.kernel.org
What should I do about it?
Update to the fixed stable release for the relevant branch: 5.10.266, 6.6.100, 6.12.40, or 6.15.8. Later kernels in those branches also include the fix.Source: git.kernel.org
Is it being exploited?
It is not in CISA's Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment does not mark exploitation as active. That does not mean it has not been attacked: vendors and researchers can report attacks before CISA lists them. No public exploit code is tracked.Source: cve.now feed data