From: Allison Henderson <achender@kernel.org>
To: Henry Martin <bsdhenrymartin@gmail.com>,
"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>
Cc: netdev@vger.kernel.org, linux-rdma@vger.kernel.org,
linux-kernel@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH] rds: fix out-of-bounds conn_path access via handshake NPATHS
Date: Sun, 11 Oct 2026 13:41:31 -0700 [thread overview]
Message-ID: <9cdaa7743cbd1e6e39345647f4ef95ab308ca7ad.camel@kernel.org> (raw)
In-Reply-To: <20261008163843.957325-1-bsdhenrymartin@gmail.com>
On Fri, 2026-10-09 at 00:38 +0800, Henry Martin wrote:
> Connections on the IB transport (t_mp_capable unset) own exactly one
> rds_conn_path slot, but the peer can still claim eight lanes through
> the NPATHS extension header of a handshake packet, and every
> subsequent fan-out path then treats all eight entries as real: the
> mp-start helper iterates conn->c_path[0..7], dereferencing cp->cp_conn,
> taking cp->cp_lock and queueing delayed work on cp->cp_wq at 504-byte
> strides into whatever comes after the single allocated slot (KASAN:
> "Read of size 8 in rds_conn_path_connect_if_down").
>
> The negotiated lane count is now clamped to the same value the
> transport was allocated with (trans->t_mp_capable ?
> RDS_MPATH_WORKERS : 1), so a peer can never ask us to walk lanes that
> do not exist.
>
> This vulnerability was discovered by Tencent CodeBuddy Security.
Hi Henry,
Thanks for the patches. This patch looked a little familiar, and it turns out this fix and the
companion patch ("fix out-of-bounds conn_path walk in peer gen update") are the same fix Paula
posted in August:
https://lore.kernel.org/netdev/20260825120132.51636-1-pamoutafpro@gmail.com/
The AI review of that version came back with some complaints:
https://lore.kernel.org/netdev/20260828230506.385788-1-kuba@kernel.org/
The good news is, I think the fix is a very simple port of a uek patch:
https://github.com/oracle/linux-uek/commit/2fdeb0513f18
If your willing to step in where this series left off, you'll want to start with the v2 thread,
and pick up the porting task described there:
https://lore.kernel.org/netdev/83915f73efb509328a3d4963b093e2cffcf9af99.camel@kernel.org/
Please send a single v2 that is just that port, against net. The fix tag ba3d1f480c7a doesnt
look like it changes the allocations. The tags you want should be:
Fixes: 840df162b3eb ("rds: reduce memory footprint for RDS when transport is RDMA")
Fixes: 905dd4184e07 ("RDS: TCP: Track peer's connection generation number")
A link to Paula's v2 would also be a nice way to credit her analysis as well.
Thanks!
Allison
>
> Cc: stable@vger.kernel.org
> Fixes: ba3d1f480c7a ("net/rds: size a connection's path set by the transport it ends up with")
> Signed-off-by: Henry Martin <bsdhenrymartin@gmail.com>
> ---
> net/rds/recv.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> --- a/net/rds/recv.c
> +++ b/net/rds/recv.c
> @@ -224,7 +224,8 @@
> /* Process extension header here */
> switch (type) {
> case RDS_EXTHDR_NPATHS:
> - new_npaths = min_t(int, RDS_MPATH_WORKERS,
> + new_npaths = min_t(int, conn->c_trans->t_mp_capable ?
> + RDS_MPATH_WORKERS : 1,
> be16_to_cpu(buffer.rds_npaths));
> break;
> case RDS_EXTHDR_GEN_NUM:
> --
> 2.43.7
next prev parent reply other threads:[~2026-10-11 20:41 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-08 16:38 [PATCH] rds: fix out-of-bounds conn_path access via handshake NPATHS Henry Martin
2026-10-08 16:46 ` sashiko-bot
2026-10-11 20:41 ` Allison Henderson [this message]
2026-10-12 16:54 ` 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=9cdaa7743cbd1e6e39345647f4ef95ab308ca7ad.camel@kernel.org \
--to=achender@kernel.org \
--cc=bsdhenrymartin@gmail.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=stable@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.