CVE-2026-72466

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

rpcrdmabcreceive_call(). The contract with the caller is that a

true return transfers ownership of rep to the backchannel path:

    rpcrdmareplyhandler()

      if (rpcrdmaisbcall(r_xprt, rep))

              return;        / bare return, skips out_post /

      ...

    out_post:

      rpcrdmapostrecvs(r_xprt, credits + ...);

Because rpcrdmabcreceive_call() 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 rpcrdmapost_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

(rpcrdmarepput() plus rpcrdmapostrecvs()).