From: sungbyeongchan <tjdqudcks0424@naver.com>
To: Allison Henderson <achender@kernel.org>,
"David S . Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@kernel.org>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Simon Horman <horms@kernel.org>,
Andy Grover <andy.grover@oracle.com>
Cc: netdev@vger.kernel.org, linux-rdma@vger.kernel.org,
rds-devel@oss.oracle.com, linux-kernel@vger.kernel.org
Subject: [PATCH net] RDS/IB: validate receive completion payload length
Date: Wed, 7 Oct 2026 05:52:04 +0900 [thread overview]
Message-ID: <20261006205204.1322102-1-tjdqudcks0424@naver.com> (raw)
An RDS/RDMA peer can declare a fragment length larger than the payload
reported by the receive completion. The receive path attaches the recycled
receive fragment without validating those lengths, allowing recvmsg() to
return stale bytes beyond the actual payload.
Validate data_len against the expected current-fragment length before
transferring fragment ownership. Disconnect and reconnect on mismatch.
The issue reproduced in two clean QEMU boots. A peer declared 4096 bytes
while posting only 16 bytes, and a receiver under a different UID obtained
4080-byte tails from prior messages in all 256 attempts in each boot. With
this change, the malformed message was not delivered, reconnection
succeeded, and a subsequent normal 4096-byte message was delivered intact.
Fixes: 1e23b3ee0e94 ("RDS/IB: Receive datagrams via IB")
Cc: stable@vger.kernel.org
Assisted-by: LLM
Signed-off-by: sungbyeongchan <tjdqudcks0424@naver.com>
---
net/rds/ib_recv.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/net/rds/ib_recv.c b/net/rds/ib_recv.c
index bd6cb3ffaa571..0daddb108c8a7 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,
}
}
+ if (data_len != min_t(u32, ic->i_recv_data_rem, RDS_FRAG_SIZE)) {
+ rds_ib_conn_error(conn,
+ "incoming fragment payload length %u, expected %u; "
+ "disconnecting and reconnecting\n",
+ data_len,
+ min_t(u32, ic->i_recv_data_rem, RDS_FRAG_SIZE));
+ goto done;
+ }
+
list_add_tail(&recv->r_frag->f_item, &ibinc->ii_frags);
recv->r_frag = NULL;
--
2.43.0
next reply other threads:[~2026-10-06 20:52 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-06 20:52 sungbyeongchan [this message]
2026-10-06 20:55 ` [PATCH net] RDS/IB: validate receive completion payload length netdev-bot+sinfo
2026-10-07 1:13 ` Allison Henderson
2026-10-09 11:52 ` netdev-bot+sashiko
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=20261006205204.1322102-1-tjdqudcks0424@naver.com \
--to=tjdqudcks0424@naver.com \
--cc=achender@kernel.org \
--cc=andy.grover@oracle.com \
--cc=davem@davemloft.net \
--cc=edumazet@kernel.org \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=rds-devel@oss.oracle.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