# CVE-2025-38524: rxrpc: Fix recv-recv race of completed call

> A race condition in the Linux kernel's rxrpc module allows a local attacker to trigger a kernel BUG, causing a denial of service.

- **Severity:** High 7.5 (`CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H`)
- **Exploited in the wild:** Not known
- **Login needed:** Not needed
- **Attackable:** Over the internet
- **Victim action needed:** Not needed
- **Fix available:** Yes
- **Published:** 16 Aug 2025
- **Updated:** 15 Oct 2026
- **Also known as:** AZL-66374, AZL-70451, BELL-CVE-2025-38524, DEBIAN-CVE-2025-38524, GHSA-569j-76w5-38vw, ROOT-OS-DEBIAN-11-CVE-2025-38524, ROOT-OS-DEBIAN-12-CVE-2025-38524, ROOT-OS-DEBIAN-13-CVE-2025-38524, ROOT-OS-UBUNTU-2204-CVE-2025-38524, ROOT-OS-UBUNTU-2404-CVE-2025-38524, UBUNTU-CVE-2025-38524

## What is CVE-2025-38524?

CVE-2025-38524 is a high-severity vulnerability in Linux kernel, published on 16 Aug 2025. An attacker can exploit it over the internet without logging in, with no action from the victim.

### Official description

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.

Weakness: CWE-362 (Concurrent Execution using Shared Resource with Improper Synchronization)

## Which versions are affected by CVE-2025-38524?

It affects 1 product.


Products: Linux kernel.

## How do I fix CVE-2025-38524?

Apply the vendor's patch.

## Is CVE-2025-38524 being exploited?

There is no known exploitation of CVE-2025-38524 in the wild and no public exploit code.

## Other vulnerabilities in Linux kernel

- [CVE-2026-53266](https://insights.sbomify.com/CVE-2026-53266/): Linux Kernel Out-of-Bounds Write (high 8.8, exploited in the wild)
- [CVE-2013-6282](https://insights.sbomify.com/CVE-2013-6282/): Linux Kernel Improper Input Validation (high 8.8, exploited in the wild)
- [CVE-2022-0185](https://insights.sbomify.com/CVE-2022-0185/): Linux Kernel Heap-Based Buffer Overflow (high 8.4, exploited in the wild)
- [CVE-2013-2094](https://insights.sbomify.com/CVE-2013-2094/): Linux Kernel Privilege Escalation (high 8.4, exploited in the wild)
- [CVE-2026-53362](https://insights.sbomify.com/CVE-2026-53362/): Linux Kernel Unspecified (high 7.8, exploited in the wild)

## Fix prompt for AI coding agents

```text
Check this codebase for CVE-2025-38524 and fix it if it is affected.

What it is: CVE-2025-38524 is a high-severity vulnerability in Linux kernel, published on 16 Aug 2025. An attacker can exploit it over the internet without logging in, with no action from the victim.
Exploitation: There is no known exploitation of CVE-2025-38524 in the wild and no public exploit code.

Affected product: Linux kernel. No package-level version data is available, so check the vendor advisory linked from the reference page.

Task:
1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.
2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.
3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.
4. Run the tests and summarise what changed and why.
5. If nothing in the project is affected, say so and change nothing.

Reference: https://insights.sbomify.com/CVE-2025-38524/ (Markdown: https://insights.sbomify.com/CVE-2025-38524/index.md)
```

## Sources

- CVE record: https://www.cve.org/CVERecord?id=CVE-2025-38524
- NVD: https://nvd.nist.gov/vuln/detail/CVE-2025-38524
- OSV: https://osv.dev/vulnerability/CVE-2025-38524

---
From sbomify Insights: https://insights.sbomify.com/CVE-2025-38524/
Summaries are generated and may contain mistakes; the official description above is the record.