CVE-2026-72466

Source
https://cve.org/CVERecord?id=CVE-2026-72466
Import Source
https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-72466.json
JSON Data
https://api.osv.dev/v1/vulns/CVE-2026-72466
Downstream
Published
2026-08-15T05:57:09.847Z
Modified
2026-08-16T03:48:48.333831875Z
Summary
xprtrdma: Fix bcall rep leak and unbounded peek
Details

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 = xdr_inline_decode(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 = xdr_inline_decode(xdr, 3 * sizeof(*p));
if (unlikely(!p))
        return true;

the short-header arm returns true without calling rpcrdmabcreceive_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 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()).

Database specific
{
    "osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/72xxx/CVE-2026-72466.json",
    "cna_assigner": "Linux"
}
References

Affected packages

Git / git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git

Affected ranges

Type
GIT
Repo
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Events
Introduced
41c8f70f5a3db7e06179186b6525fd9ee1d7d314
Fixed
0cee8f9c3b14bd6dee9c4310090a7f45b89b834f
Fixed
7afc2f8d2fd9394724df9eaf22ce7a71029a5fba
Fixed
88b5346284a184a6b7d019912232a571d672d3e3
Fixed
07aa506436be7634e381e1e1f6d0efa9efc81ecc
Fixed
d7a2870dde3bb09d51d6b9c877642996ad6b92dd
Fixed
118a16a18c59f7ad8084b2d13988839b669fca10
Fixed
c7653d5cebc8492c77ec0415b5e9c0fb3e644bc6

Database specific

source
"https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-72466.json"

Linux / Kernel

Package

Name
Kernel

Affected ranges

Type
ECOSYSTEM
Events
Introduced
4.14.0
Fixed
5.15.212
Type
ECOSYSTEM
Events
Introduced
5.16.0
Fixed
6.1.178
Type
ECOSYSTEM
Events
Introduced
6.2.0
Fixed
6.6.145
Type
ECOSYSTEM
Events
Introduced
6.7.0
Fixed
6.12.97
Type
ECOSYSTEM
Events
Introduced
6.13.0
Fixed
6.18.40
Type
ECOSYSTEM
Events
Introduced
6.19.0
Fixed
7.1.5

Database specific

source
"https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-72466.json"