All of lore.kernel.org
 help / color / mirror / Atom feed
From: Allison Henderson <achender@kernel.org>
To: Henry Martin <bsdhenrymartin@gmail.com>,
	Paula <pamoutafpro@gmail.com>,
	 "David S . Miller" <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>,
	Eric Dumazet <edumazet@kernel.org>,
	Paolo Abeni <pabeni@redhat.com>, Simon Horman <horms@kernel.org>
Cc: linux-rdma@vger.kernel.org, netdev@vger.kernel.org,
	 linux-kernel@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH net v2] rds: fix out-of-bounds conn_path walks via handshake exthdrs
Date: Wed, 14 Oct 2026 22:29:37 -0700	[thread overview]
Message-ID: <220faca993d7a88c356b1e146f4a4397eedfe5de.camel@kernel.org> (raw)
In-Reply-To: <20261012025336.54756-1-bsdhenrymartin@gmail.com>

On Mon, 2026-10-12 at 10:53 +0800, Henry Martin wrote:
> Both the lane and the connection-generation negotiation are driven by
> extension headers in handshake packets, and both are processed
> unconditionally, even on transports that are not multipath capable.
> A non-MP connection (t_mp_capable unset) owns exactly one
> rds_conn_path slot, so a peer claiming up to RDS_MPATH_WORKERS lanes
> makes every subsequent fan-out walk conn->c_path[0..7] at 504-byte
> strides past the single allocated slot (KASAN: "Read of size 8 in
> rds_conn_path_connect_if_down"); the generation negotiation opens a
> similar out-of-bounds walk on the same array.
> 
> Only process handshake extension headers when the connection's
> transport is multipath capable, so a peer can never make us walk
> lanes that do not exist.  Both call sites in rds_recv_incoming() are
> gated.
> 
> This is a port of the Oracle UEK fix for the same issue, picked up
> where Paula's series of the same change left off.
> 
> This issue was discovered by Tencent CodeBuddy Security.
> 
> Cc: stable@vger.kernel.org
> Link: https://lore.kernel.org/netdev/20260825120132.51636-1-pamoutafpro@gmail.com/
> Link: https://github.com/oracle/linux-uek/commit/2fdeb0513f18
> Fixes: 840df162b3eb ("rds: reduce memory footprint for RDS when transport is RDMA")
> Fixes: 905dd4184e07 ("RDS: TCP: Track peer's connection generation number")
> Signed-off-by: Henry Martin <bsdhenrymartin@gmail.com>

Hi Henry,

Looks like a straight forward port.  Thank you!

Reviewed-by: Allison Henderson <achender@kernel.org>
Tested-by: Allison Henderson <achender@kernel.org>

Thank you!
Allison

> ---
> 
> v2: Replace the two allocation-bound clamps with a port of the UEK
>     t_mp_capable handshake gating (suggested by Allison Henderson),
>     correct the Fixes tags and link Paula's series.
> 
>  net/rds/recv.c | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/net/rds/recv.c b/net/rds/recv.c
> index 6204e577a90ae..93ee4546ae362 100644
> --- a/net/rds/recv.c
> +++ b/net/rds/recv.c
> @@ -379,7 +379,8 @@ void rds_recv_incoming(struct rds_connection *conn, struct in6_addr *saddr,
>  		rds_stats_inc(s_recv_ping);
>  		rds_send_pong(cp, inc->i_hdr.h_sport);
>  		/* if this is a handshake ping, start multipath if necessary */
> -		if (RDS_HS_PROBE(be16_to_cpu(inc->i_hdr.h_sport),
> +		if (conn->c_trans->t_mp_capable &&
> +		    RDS_HS_PROBE(be16_to_cpu(inc->i_hdr.h_sport),
>  				 be16_to_cpu(inc->i_hdr.h_dport))) {
>  			rds_recv_hs_exthdrs(&inc->i_hdr, cp->cp_conn);
>  			rds_start_mprds(cp->cp_conn);
> @@ -387,7 +388,8 @@ void rds_recv_incoming(struct rds_connection *conn, struct in6_addr *saddr,
>  		goto out;
>  	}
>  
> -	if (be16_to_cpu(inc->i_hdr.h_dport) ==  RDS_FLAG_PROBE_PORT &&
> +	if (conn->c_trans->t_mp_capable &&
> +	    be16_to_cpu(inc->i_hdr.h_dport) ==  RDS_FLAG_PROBE_PORT &&
>  	    inc->i_hdr.h_sport == 0) {
>  		rds_recv_hs_exthdrs(&inc->i_hdr, cp->cp_conn);
>  		/* if this is a handshake pong, start multipath if necessary */


  parent reply	other threads:[~2026-10-15  5:29 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-12  2:53 [PATCH net v2] rds: fix out-of-bounds conn_path walks via handshake exthdrs Henry Martin
2026-10-12  3:06 ` sashiko-bot
2026-10-15  5:29 ` Allison Henderson [this message]
2026-10-16  1:00 ` patchwork-bot+netdevbpf

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=220faca993d7a88c356b1e146f4a4397eedfe5de.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=pamoutafpro@gmail.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.