All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: linux-cve-announce@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@kernel.org>
Subject: CVE-2026-72466: xprtrdma: Fix bcall rep leak and unbounded peek
Date: Sat, 15 Aug 2026 15:09:05 +0900	[thread overview]
Message-ID: <2026081534-CVE-2026-72466-3fcf@gregkh> (raw)

From: Greg Kroah-Hartman <gregkh@kernel.org>

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

The Linux kernel CVE team has assigned CVE-2026-72466 to this issue.


Affected and fixed versions
===========================

	Issue introduced in 4.14 with commit 41c8f70f5a3db7e06179186b6525fd9ee1d7d314 and fixed in 5.15.212 with commit 0cee8f9c3b14bd6dee9c4310090a7f45b89b834f
	Issue introduced in 4.14 with commit 41c8f70f5a3db7e06179186b6525fd9ee1d7d314 and fixed in 6.1.178 with commit 7afc2f8d2fd9394724df9eaf22ce7a71029a5fba
	Issue introduced in 4.14 with commit 41c8f70f5a3db7e06179186b6525fd9ee1d7d314 and fixed in 6.6.145 with commit 88b5346284a184a6b7d019912232a571d672d3e3
	Issue introduced in 4.14 with commit 41c8f70f5a3db7e06179186b6525fd9ee1d7d314 and fixed in 6.12.97 with commit 07aa506436be7634e381e1e1f6d0efa9efc81ecc
	Issue introduced in 4.14 with commit 41c8f70f5a3db7e06179186b6525fd9ee1d7d314 and fixed in 6.18.40 with commit d7a2870dde3bb09d51d6b9c877642996ad6b92dd
	Issue introduced in 4.14 with commit 41c8f70f5a3db7e06179186b6525fd9ee1d7d314 and fixed in 7.1.5 with commit 118a16a18c59f7ad8084b2d13988839b669fca10
	Issue introduced in 4.14 with commit 41c8f70f5a3db7e06179186b6525fd9ee1d7d314 and fixed in 7.2-rc1 with commit c7653d5cebc8492c77ec0415b5e9c0fb3e644bc6

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2026-72466
will be updated if fixes are backported, please check that for the most
up to date information about this issue.


Affected files
==============

The file(s) affected by this issue are:
	net/sunrpc/xprtrdma/rpc_rdma.c


Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/0cee8f9c3b14bd6dee9c4310090a7f45b89b834f
	https://git.kernel.org/stable/c/7afc2f8d2fd9394724df9eaf22ce7a71029a5fba
	https://git.kernel.org/stable/c/88b5346284a184a6b7d019912232a571d672d3e3
	https://git.kernel.org/stable/c/07aa506436be7634e381e1e1f6d0efa9efc81ecc
	https://git.kernel.org/stable/c/d7a2870dde3bb09d51d6b9c877642996ad6b92dd
	https://git.kernel.org/stable/c/118a16a18c59f7ad8084b2d13988839b669fca10
	https://git.kernel.org/stable/c/c7653d5cebc8492c77ec0415b5e9c0fb3e644bc6

                 reply	other threads:[~2026-08-15  6:29 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2026081534-CVE-2026-72466-3fcf@gregkh \
    --to=gregkh@linuxfoundation.org \
    --cc=cve@kernel.org \
    --cc=gregkh@kernel.org \
    --cc=linux-cve-announce@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.