Linux kernel CVE announcements
 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-72464: xprtrdma: Repost Receive buffers for malformed replies
Date: Sat, 15 Aug 2026 15:09:03 +0900	[thread overview]
Message-ID: <2026081533-CVE-2026-72464-e38f@gregkh> (raw)

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

Description
===========

In the Linux kernel, the following vulnerability has been resolved:

xprtrdma: Repost Receive buffers for malformed replies

rpcrdma_wc_receive() decrements the transport's Receive count for
every completion before it dispatches a successful Receive to
rpcrdma_reply_handler(). The handler must post a replacement
Receive WR before returning unless ownership of the rep has moved
elsewhere, as on the backchannel path.

Commit 2ae50ad68cd7 ("xprtrdma: Close window between waking RPC
senders and posting Receives") moved the Receive refill out of
rpcrdma_wc_receive(), where it had run ahead of every reply, into
rpcrdma_reply_handler() so that the responder's credit grant could
be parsed before reposting. The bad-version and short-reply exits
never reach that refill: they recycle the rep and return without
calling rpcrdma_post_recvs().

A remote peer can therefore drain the client's posted Receive
queue by sending a sustained stream of replies that are shorter
than the fixed transport header or that carry an unrecognized
RPC/RDMA version. Each such reply consumes one posted Receive
without replacing it. Once the queue empties, the peer's next
Send finds no posted Receive and the transport stalls until
reconnect.

Route both malformed-reply exits through the shared repost tail
after recycling the rep, refilling against buf->rb_credits, the
most recent accepted credit grant. Neither exit updates the
congestion window, so RPCs admitted under the previous grant
remain in flight awaiting replies. A smaller refill target would
let a stream of malformed replies ratchet the posted Receive count
down to the batch floor while the congestion window still admits
rb_credits RPCs; a burst of valid replies to those RPCs could then
overrun the posted Receives, and because the client connects with
rnr_retry_count of zero, a single RNR NAK terminates the
connection. Refilling against rb_credits also restores the target
that applied to malformed replies before commit 2ae50ad68cd7
("xprtrdma: Close window between waking RPC senders and posting
Receives") when rpcrdma_post_recvs() computed it from rb_credits
internally. rb_credits is at least one from connection
establishment onward, so the repost path always keeps Receives
posted.

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


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

	Issue introduced in 5.5 with commit 2ae50ad68cd79224198b525f7bd645c9da98b6ff and fixed in 6.1.178 with commit ef6fb8a5c521f1a07f85202d13e8f2898f247362
	Issue introduced in 5.5 with commit 2ae50ad68cd79224198b525f7bd645c9da98b6ff and fixed in 6.6.145 with commit 4322fd9645ee769ad29ce5caea74a1cd9b17269d
	Issue introduced in 5.5 with commit 2ae50ad68cd79224198b525f7bd645c9da98b6ff and fixed in 6.12.97 with commit 19fae02b272ee4bcdfb5db57f402d28f1697167a
	Issue introduced in 5.5 with commit 2ae50ad68cd79224198b525f7bd645c9da98b6ff and fixed in 6.18.40 with commit 007b4da2f38dcc16a13265416f4ca9f179bab610
	Issue introduced in 5.5 with commit 2ae50ad68cd79224198b525f7bd645c9da98b6ff and fixed in 7.1.5 with commit d7c531ab477ae94fd03771d707fd29c787408039
	Issue introduced in 5.5 with commit 2ae50ad68cd79224198b525f7bd645c9da98b6ff and fixed in 7.2-rc1 with commit abc011ddaf1617e3e82d8a1e87daa7ddbfb9bac5
	Issue introduced in 5.4.13 with commit 3791c5982ba1eebf2900ee7ca7b9a89619c26d54

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-72464
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/ef6fb8a5c521f1a07f85202d13e8f2898f247362
	https://git.kernel.org/stable/c/4322fd9645ee769ad29ce5caea74a1cd9b17269d
	https://git.kernel.org/stable/c/19fae02b272ee4bcdfb5db57f402d28f1697167a
	https://git.kernel.org/stable/c/007b4da2f38dcc16a13265416f4ca9f179bab610
	https://git.kernel.org/stable/c/d7c531ab477ae94fd03771d707fd29c787408039
	https://git.kernel.org/stable/c/abc011ddaf1617e3e82d8a1e87daa7ddbfb9bac5

                 reply	other threads:[~2026-08-15  6:31 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=2026081533-CVE-2026-72464-e38f@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox