From: Chuck Lever <cel@kernel.org>
To: 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-rdma@vger.kernel.org, linux-nfs@vger.kernel.org,
Chuck Lever <chuck.lever@oracle.com>, Chris Mason <clm@meta.com>,
Chuck Lever <chuck.lever@oracle.com>
Subject: [PATCH 0/6] svcrdma: harden parsed chunk list against malformed wire values
Date: Tue, 26 May 2026 09:35:54 -0400 [thread overview]
Message-ID: <20260526-rpc-kernel-bugs-v1-0-e251306ccca9@oracle.com> (raw)
The RPC/RDMA transport stores wire-supplied chunk positions, lengths,
and segment counts verbatim in the parsed chunk list. Consumer
functions compute gap lengths and sub-range offsets from these values
using unsigned subtraction. A malicious or buggy peer can supply
values that cause these subtractions to underflow, exposing slab
memory to the Reply channel or driving oversized allocations.
The fix proceeds in two layers. Consumer functions in svc_rdma_rw.c
gain bounds checks against the saved inline body length before each
unsigned subtraction, closing the immediate underflow paths. The
Read list decoder in svc_rdma_recvfrom.c gains a segment-length cap
against the receive context's page budget, and the existing page-
overrun guard in svc_rdma_build_read_segment() is corrected to
release the rw context it has already acquired. These consumer-side
fixes are backportable independently.
pcl_for_each_segment() uses an inclusive upper bound that underflows
when ch_segcount is zero, turning a zero-segment Write or Reply
chunk into an unbounded memory walk. The macro is changed to a
half-open bound that naturally produces an empty iteration for
ch_segcount == 0. The decoder then also rejects zero-segment chunks
at the wire boundary, and reorders pcl_alloc_write() so that only
fully-populated chunks appear on the list. The macro fix remains as
defense in depth and is safe to backport to trees without the decoder
change.
A consolidation pass validates Read chunk positions and overlap
invariants once, immediately after decoding, so that future PCL
consumers inherit the guarantee without replicating per-site checks.
---
Chris Mason (3):
svcrdma: Fix offset arithmetic in read_chunk_range
svcrdma: fix pcl_for_each_segment for empty chunks
svcrdma: reject Write/Reply chunks with segcount 0
Chuck Lever (3):
svcrdma: validate Read chunk positions before reconstruction
svcrdma: reject oversized Read segments at decode time
svcrdma: Validate Read chunk positions at decode time
include/linux/sunrpc/svc_rdma_pcl.h | 4 ++-
net/sunrpc/xprtrdma/svc_rdma_pcl.c | 63 ++++++++++++++++++++++++++++++---
net/sunrpc/xprtrdma/svc_rdma_recvfrom.c | 14 ++++++--
net/sunrpc/xprtrdma/svc_rdma_rw.c | 52 ++++++++++++++++++++-------
4 files changed, 113 insertions(+), 20 deletions(-)
---
base-commit: 887d478bb2115cec0be8caae58bad4d4b3109b1a
change-id: 20260524-rpc-kernel-bugs-fb537a0615ec
Best regards,
--
Chuck Lever <chuck.lever@oracle.com>
next reply other threads:[~2026-05-26 13:36 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-26 13:35 Chuck Lever [this message]
2026-05-26 13:35 ` [PATCH 1/6] svcrdma: validate Read chunk positions before reconstruction Chuck Lever
2026-05-26 13:35 ` [PATCH 2/6] svcrdma: Fix offset arithmetic in read_chunk_range Chuck Lever
2026-05-26 13:35 ` [PATCH 3/6] svcrdma: reject oversized Read segments at decode time Chuck Lever
2026-05-26 13:35 ` [PATCH 4/6] svcrdma: fix pcl_for_each_segment for empty chunks Chuck Lever
2026-05-26 13:35 ` [PATCH 5/6] svcrdma: reject Write/Reply chunks with segcount 0 Chuck Lever
2026-05-26 13:36 ` [PATCH 6/6] svcrdma: Validate Read chunk positions at decode time Chuck Lever
2026-05-27 15:19 ` [PATCH 0/6] svcrdma: harden parsed chunk list against malformed wire values Jeff Layton
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=20260526-rpc-kernel-bugs-v1-0-e251306ccca9@oracle.com \
--to=cel@kernel.org \
--cc=Dai.Ngo@oracle.com \
--cc=chuck.lever@oracle.com \
--cc=clm@meta.com \
--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=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