# CVE-2026-72464: xprtrdma: Repost Receive buffers for malformed replies

> A remote peer can cause a denial of service in the Linux kernel's xprtrdma module by sending malformed replies that exhaust the receive queue.

- **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:** 15 Aug 2026
- **Updated:** 16 Oct 2026
- **Also known as:** BELL-CVE-2026-72464, DEBIAN-CVE-2026-72464, GHSA-34qj-fwq9-4829, UBUNTU-CVE-2026-72464

## What is CVE-2026-72464?

CVE-2026-72464 is a high-severity denial of service vulnerability in Linux, published on 15 Aug 2026. 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:

xprtrdma: Repost Receive buffers for malformed replies

rpcrdma_wc_receive() decrements the transport's Receive count for
every completion before it dispatches a successful Receive to
rpcrdma_reply_handler(). The handler must post a replacement
Receive WR before returning unless ownership of the rep has moved
elsewhere, as on the backchannel path.

Commit 2ae50ad68cd7 ("xprtrdma: Close window between waking RPC
senders and posting Receives") moved the Receive refill out of
rpcrdma_wc_receive(), where it had run ahead of every reply, into
rpcrdma_reply_handler() so that the responder's credit grant could
be parsed before reposting. The bad-version and short-reply exits
never reach that refill: they recycle the rep and return without
calling rpcrdma_post_recvs().

A remote peer can therefore drain the client's posted Receive
queue by sending a sustained stream of replies that are shorter
than the fixed transport header or that carry an unrecognized
RPC/RDMA version. Each such reply consumes one posted Receive
without replacing it. Once the queue empties, the peer's next
Send finds no posted Receive and the transport stalls until
reconnect.

Route both malformed-reply exits through the shared repost tail
after recycling the rep, refilling against buf->rb_credits, the
most recent accepted credit grant. Neither exit updates the
congestion window, so RPCs admitted under the previous grant
remain in flight awaiting replies. A smaller refill target would
let a stream of malformed replies ratchet the posted Receive count
down to the batch floor while the congestion window still admits
rb_credits RPCs; a burst of valid replies to those RPCs could then
overrun the posted Receives, and because the client connects with
rnr_retry_count of zero, a single RNR NAK terminates the
connection. Refilling against rb_credits also restores the target
that applied to malformed replies before commit 2ae50ad68cd7
("xprtrdma: Close window between waking RPC senders and posting
Receives") when rpcrdma_post_recvs() computed it from rb_credits
internally. rb_credits is at least one from connection
establishment onward, so the repost path always keeps Receives
posted.

## Which versions are affected by CVE-2026-72464?


## How do I fix CVE-2026-72464?

Apply the vendor's patch.

## Is CVE-2026-72464 being exploited?

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

## Fix prompt for AI coding agents

```text
Check this codebase for CVE-2026-72464 and fix it if it is affected.

What it is: CVE-2026-72464 is a high-severity denial of service vulnerability in Linux, published on 15 Aug 2026. 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-2026-72464 in the wild and no public exploit code.

Affected product: Linux. 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-2026-72464/ (Markdown: https://insights.sbomify.com/CVE-2026-72464/index.md)
```

## Sources

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

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