Linux RDMA and InfiniBand development
 help / color / mirror / Atom feed
From: Hyunsol Mun <muumthf@gmail.com>
To: Chuck Lever <cel@kernel.org>, Jeff Layton <jlayton@kernel.org>,
	NeilBrown <neil@brown.name>,
	Olga Kornievskaia <okorniev@redhat.com>,
	Dai Ngo <Dai.Ngo@oracle.com>, Tom Talpey <tom@talpey.com>
Cc: linux-nfs@vger.kernel.org, linux-rdma@vger.kernel.org,
	bobtobabz@gmail.com, stable@vger.kernel.org
Subject: [PATCH] svcrdma: silently discard undersized messages
Date: Thu, 22 Oct 2026 12:46:29 +0900	[thread overview]
Message-ID: <20261022034629.430954-1-muumthf@gmail.com> (raw)

RFC 8166 requires an RPC-over-RDMA message shorter than the 28-byte
minimum header to be silently discarded because its XID cannot be
trusted.

svc_rdma_xdr_decode_req() instead returns -EINVAL when the fixed header
cannot be decoded. svc_rdma_recvfrom() turns that into an RDMA_ERROR,
whose encoder copies the first two words from rc_recv_buf without
checking rc_byte_len. A zero- to seven-byte SEND can therefore return
up to eight bytes that were not supplied by the peer.

Check the complete minimum header length before parsing and use the
decoder's existing silent-drop return for undersized input. This keeps
the error encoder from reading beyond the received message and follows
the protocol requirement.

On an unpatched nfsd-testing kernel at 764ffa45f3f2, a two-VM Soft-iWARP
test sent 128 complete 28-byte bad-version headers over connection A.
After closing that connection, it sent 128 zero-byte SENDs over
connection B. All 128 zero-byte requests received replies, and 56 of
those replies contained the exact XID and version markers left by
connection A. The test process ran as uid/gid 65534 with no effective
capabilities and NoNewPrivs set.

With this patch applied, all eight complete 28-byte bad-version headers
elicited replies. A zero-byte SEND and a 27-byte SEND each elicited no
reply during a five-second observation interval. A normal NFSv4.1/RDMA
mount, write, readback, and unmount completed successfully. The server
remained running without an oops or panic. Both x86-64 kernels built
with GCC 12.2 and CONFIG_WERROR=y without warnings.

The vulnerability research and validation were conducted by members of
the Tobabz team as part of the Best of the Best 15th program.

Fixes: f3ea53fb3bc3 ("svcrdma: Use correct XID in error replies")
Cc: stable@vger.kernel.org
Assisted-by: LLM
Signed-off-by: Hyunsol Mun <muumthf@gmail.com>
---
 net/sunrpc/xprtrdma/svc_rdma_recvfrom.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/net/sunrpc/xprtrdma/svc_rdma_recvfrom.c b/net/sunrpc/xprtrdma/svc_rdma_recvfrom.c
index ed5a83e9edd2..f2fbba4b30d4 100644
--- a/net/sunrpc/xprtrdma/svc_rdma_recvfrom.c
+++ b/net/sunrpc/xprtrdma/svc_rdma_recvfrom.c
@@ -714,6 +714,9 @@ static int svc_rdma_xdr_decode_req(struct xdr_buf *rq_arg,
 	__be32 *p, *rdma_argp;
 	unsigned int hdr_len;
 
+	if (unlikely(rq_arg->len < RPCRDMA_HDRLEN_MIN))
+		goto out_short;
+
 	rdma_argp = rq_arg->head[0].iov_base;
 	xdr_init_decode(&rctxt->rc_stream, rq_arg, rdma_argp, NULL);
 
@@ -758,7 +761,7 @@ static int svc_rdma_xdr_decode_req(struct xdr_buf *rq_arg,
 
 out_short:
 	trace_svcrdma_decode_short_err(rctxt, rq_arg->len);
-	return -EINVAL;
+	return 0;
 
 out_version:
 	trace_svcrdma_decode_badvers_err(rctxt, rdma_argp);

base-commit: 764ffa45f3f2189cd86ec6d46d248fc0440507b6
-- 
2.50.1 (Apple Git-155)


             reply	other threads:[~2026-10-22  3:46 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-22  3:46 Hyunsol Mun [this message]
2026-10-22  3:54 ` [PATCH] svcrdma: silently discard undersized messages sashiko-bot
2026-10-22 12:47 ` Chuck Lever

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=20261022034629.430954-1-muumthf@gmail.com \
    --to=muumthf@gmail.com \
    --cc=Dai.Ngo@oracle.com \
    --cc=bobtobabz@gmail.com \
    --cc=cel@kernel.org \
    --cc=jlayton@kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=neil@brown.name \
    --cc=okorniev@redhat.com \
    --cc=stable@vger.kernel.org \
    --cc=tom@talpey.com \
    /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