CVE-2026-72466 xprtrdma: Fix bcall rep leak and unbounded peek

Critical 9.8 Published Updated

A flaw in the Linux kernel's xprtrdma module allows remote attackers to cause a denial of service by draining the Receive queue through malformed replies.

Exploited in the wild
Not known
Login needed
Not needed
Attackable
Over the internet
Victim action needed
Not needed
Fix
Available

What is CVE-2026-72466?

CVE-2026-72466 is a critical 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: Fix bcall rep leak and unbounded peek

rpcrdma_is_bcall() decodes a reply's first words to decide whether the frame is a backchannel call. Two issues in that decode path let a short or malformed reply leak the receive buffer and drain the Receive queue.

First, the speculative peek

p = xdr_inline_decode(xdr, 0); /* five p++ reads follow */

asks xdr_inline_decode() for zero bytes, which returns xdr->p without consulting xdr->end. The five subsequent __be32 reads can then walk up to 20 bytes past the wire payload into stale regbuf contents and misclassify the reply as a backchannel call.

Second, after the post-peek

p = xdr_inline_decode(xdr, 3 * sizeof(*p)); if (unlikely(!p)) return true;

the short-header arm returns true without calling rpcrdma_bc_receive_call(). The contract with the caller is that a true return transfers ownership of rep to the backchannel path:

rpcrdma_reply_handler() if (rpcrdma_is_bcall(r_xprt, rep)) return; /* bare return, skips out_post */ ... out_post: rpcrdma_post_recvs(r_xprt, credits + ...);

Because rpcrdma_bc_receive_call() never ran, no one took rep, but rpcrdma_reply_handler still bare-returns past rpcrdma_rep_put() and rpcrdma_post_recvs(). The rep, with its persistently DMA-mapped receive buffer, is orphaned on rb_all_reps and freed only at transport teardown. This completion reposts nothing, so its slot is reclaimed only when a later forward-channel reply reaches out_post and rpcrdma_post_recvs() allocates a fresh rep to backfill; absent that traffic the Receive queue drains and the peer's Sends draw RNR NAKs.

Fix by consulting xdr->end after the zero-length peek so the five __be32 reads cannot run unless 20 bytes of wire payload remain. A byte-precise comparison against xdr->end is required because a non-4-aligned receive rounds the stream's word count up past the true payload. Also return false from the short-header arm so the reply falls through the normal out_norqst cleanup chain (rpcrdma_rep_put() plus rpcrdma_post_recvs()).

Which versions are affected by CVE-2026-72466?

How do I fix CVE-2026-72466?

Apply the vendor's patch.

Upgrade, then put limits on request size, rate and nesting depth so one client cannot exhaust the service. More about Denial of service.

Is CVE-2026-72466 being exploited?

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

Sources

Also known as BELL-CVE-2026-72466, DEBIAN-CVE-2026-72466, GHSA-7c5h-c675-2hvr, UBUNTU-CVE-2026-72466.

Is CVE-2026-72466 in your software?

Upload an SBOM and sbomify checks it against every vulnerability here, every day.

Check your SBOMs for free