From: sashiko-bot@kernel.org
To: "Shubham Antil" <shubham@octane.security>
Cc: linux-rdma@vger.kernel.org
Subject: Re: [PATCH net v2] net/rds: ib: drop fragments shorter than the header-declared length
Date: Thu, 08 Oct 2026 06:21:52 +0000 [thread overview]
Message-ID: <sashiko-outbox-163683@kernel.org> (raw)
In-Reply-To: <20261007062135.49946-1-shubham@octane.security>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] rds: Denial of Service (connection drop) via fragmented ZCOPY messages
--
commit 99e06641e00267bc78ccb17feb870bd7545f3c4f
Author: Shubham Antil <shubham@octane.security>
net/rds: ib: drop fragments shorter than the header-declared length
This commit introduces a strict length check in rds_ib_process_recv() to drop
incoming fragments that are shorter than the header-declared length. This is
intended to prevent uninitialized memory in the fragment page from being copied
to userspace.
Closes: https://lore.kernel.org/netdev/20261006205204.1322102-1-tjdqudcks0424@naver.com/
> diff --git a/net/rds/ib_recv.c b/net/rds/ib_recv.c
> index bd6cb3ffaa571..fee77b6d7ffb2 100644
> --- a/net/rds/ib_recv.c
> +++ b/net/rds/ib_recv.c
> @@ -949,6 +949,15 @@ static void rds_ib_process_recv(struct rds_connection *conn,
> }
> }
>
> + /* h_len must be backed by the payload actually received (data_len),
> + * else the unwritten frag-page tail is copied to userspace.
> + */
> + if (data_len < min_t(u32, ic->i_recv_data_rem, RDS_FRAG_SIZE)) {
> + rds_ib_conn_error(conn,
> + "fragment shorter than header-declared length; forcing reconnect\n");
> + goto done;
> + }
> +
[Severity: High]
Does this new check assume all non-final fragments are perfectly sized to
RDS_FRAG_SIZE?
When a user calls sendmsg() on an RDS socket with zero-copy enabled, passing
an iovec array where intermediate elements are smaller than RDS_FRAG_SIZE,
rds_message_zcopy_from_user() preserves these small user buffers by creating
small SG elements.
Looking at rds_ib_xmit() in net/rds/ib_send.c, the sender does not coalesce
small SG elements across RDS_FRAG_SIZE boundaries:
len = min(RDS_FRAG_SIZE,
sg_dma_len(scat) - rm->data.op_dmaoff);
send->s_wr.num_sge = 2;
send->s_sge[1].addr = sg_dma_address(scat);
send->s_sge[1].addr += rm->data.op_dmaoff;
send->s_sge[1].length = len;
send->s_sge[1].lkey = ic->i_pd->local_dma_lkey;
bytes_sent += len;
rm->data.op_dmaoff += len;
if (rm->data.op_dmaoff == sg_dma_len(scat)) {
scat++;
Because rds_ib_xmit() directly creates an IB SEND fragment bounded by the
small SG element length, the received fragment might legitimately be smaller
than RDS_FRAG_SIZE even if it is not the final fragment of the message.
Could this allow any local user with RDS access to trivially tear down active
RDS IB connections by sending a valid zero-copy message constructed with small
iovec lengths, causing rds_ib_conn_error() to be hit on the receiver?
> list_add_tail(&recv->r_frag->f_item, &ibinc->ii_frags);
> recv->r_frag = NULL;
>
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261007062135.49946-1-shubham@octane.security?part=1
prev parent reply other threads:[~2026-10-08 6:21 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-07 6:21 [PATCH net v2] net/rds: ib: drop fragments shorter than the header-declared length Shubham Antil
2026-10-08 6:21 ` sashiko-bot [this message]
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=sashiko-outbox-163683@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=shubham@octane.security \
/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