Get a Demo

Let's Patch It!

Book a short call with one our specialists, we'll walk you through how Endor Patches work, and ask you a few questions about your environment (like your primary programming languages and repository management). We'll also send you an email right after you fill out the form, feel free to reply with any questions you have in advance!

CVE

DEBIAN-CVE-2026-72466

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 ...
Back to all
CVE

DEBIAN-CVE-2026-72466

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 ...

In the Linux kernel, the following vulnerability has been resolved:  xprtrdma: Fix bcall rep leak and unbounded peek  rpcrdmaisbcall() 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 = xdrinlinedecode(xdr, 0);     / five p++ reads follow /  asks xdrinlinedecode() 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 = xdrinlinedecode(xdr, 3  sizeof(p));     if (unlikely(!p))             return true;  the short-header arm returns true without calling rpcrdmabcreceivecall(). The contract with the caller is that a true return transfers ownership of rep to the backchannel path:      rpcrdmareplyhandler()       if (rpcrdmaisbcall(rxprt, rep))               return;        /* bare return, skips outpost */       ...     outpost:       rpcrdmapostrecvs(rxprt, credits + ...);  Because rpcrdmabcreceivecall() never ran, no one took rep, but rpcrdmareplyhandler still bare-returns past rpcrdmarepput() and rpcrdmapostrecvs(). The rep, with its persistently DMA-mapped receive buffer, is orphaned on rballreps and freed only at transport teardown. This completion reposts nothing, so its slot is reclaimed only when a later forward-channel reply reaches outpost and rpcrdmapostrecvs() 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 outnorqst cleanup chain (rpcrdmarepput() plus rpcrdmapostrecvs()).

Package Versions Affected

Package Version
patch Availability
No items found.

Automatically patch vulnerabilities without upgrading

Fix Without Upgrading
Detect compatible fix
Apply safe remediation
Fix with a single pull request

CVSS Version

Severity
Base Score
CVSS Version
Score Vector
C
H
U
-
C
H
U
0
-
3.1
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
C
H
U
-

Related Resources

No items found.

References

https://security-tracker.debian.org/tracker/CVE-2026-72466

Severity

9.8

CVSS Score
0
10

Basic Information

Base CVSS
9.8
EPSS Probability
0%
EPSS Percentile
0%
Introduced Version
0
Fix Available
6.1.180-1,6.12.100-1,7.1.5-1

Fix Critical Vulnerabilities Instantly

Secure your app without upgrading.
Fix Without Upgrading