[rds-devel] [External] : Re: [PATCH net v4] RDS/IB: validate receive fragment completions

[Allison Henderson]

On Tue, 2026-10-13 at 08:27 +0530, Shubham Antil wrote:
> rds_ib_process_recv() accounts every receive fragment as contributing
> min(i_recv_data_rem, RDS_FRAG_SIZE) bytes, regardless of the completion
> length. When a completion is shorter than the header-declared amount,
> receive accounting can advance beyond the payload supplied by the
> completion.
> 
> Only an IB_WC_RECV completion has the buffer layout expected by this
> receive path. Other successful completion opcodes must not be interpreted
> as ordinary receive completions.
> 
> Reject successful completions with any other opcode before processing
> their length. For ordinary receive completions, require enough payload
> to cover the amount accounted to the fragment before linking its page
> into the incoming message.
> 
> This is compatible with the current transmit paths. MSG_ZEROCOPY is
> restricted to RDS/TCP, while RDS/IB copied and page-vector messages use
> full-sized non-final scatterlist entries.
> 
> Found during an LLM-assisted source audit and validated under KMSAN with
> a malformed short receive completion.
> 
> Reported-by: sungbyeongchan <tjdqudcks0424 at naver.com>
> Closes: https://lore.kernel.org/netdev/20261006205204.1322102-1-tjdqudcks0424@naver.com/
> Reported-by: Giovanni Vignone <gio at octane.security>
> Link: https://lore.kernel.org/netdev/8a6ee1d5336ae65b8ffdc8c40a1135657207e204.camel@kernel.org/
> Reported-by: Robert van Eijk <robert at octane.security>
> Link: https://lore.kernel.org/netdev/8a6ee1d5336ae65b8ffdc8c40a1135657207e204.camel@kernel.org/
> Reported-by: Paolo Gentry <paolo at octane.security>
> Link: https://lore.kernel.org/netdev/8a6ee1d5336ae65b8ffdc8c40a1135657207e204.camel@kernel.org/
> Fixes: 1e23b3ee0e94 ("RDS/IB: Receive datagrams via IB")
> Cc: stable at vger.kernel.org
> Assisted-by: LLM (OpenAI Codex, gpt-5.6-sol)
> Signed-off-by: Shubham Antil <shubham at octane.security>
Thanks Shubham, 

This version looks good to me. I also tested it and found no regressions. 
Reviewed-by: Allison Henderson <achender at kernel.org>
Tested-by: Allison Henderson <achender at kernel.org>

Thank you!
Allison

> ---
> Changes in v4:
> - Reject malformed short fragments instead of normalizing their length.
> - Reject successful non-IB_WC_RECV completions before trusting byte_len.
> - Explain why MSG_ZEROCOPY cannot reach the RDS/IB transmit path.
> - Add the source-audit and KMSAN discovery details.
> - Remove the author's self-Reported-by while retaining linked reporters.
> - Leave maximum h_len validation to a separate investigation.
> 
> v3: https://lore.kernel.org/netdev/20261008124940.13371-1-shubham@octane.security/
> v2: https://lore.kernel.org/netdev/20261007062135.49946-1-shubham@octane.security/
> 
>  net/rds/ib_recv.c | 13 ++++++++++++-
>  1 file changed, 12 insertions(+), 1 deletion(-)
> 
> diff --git a/net/rds/ib_recv.c b/net/rds/ib_recv.c
> index bd6cb3ffaa..aa50b85b0f 100644
> --- a/net/rds/ib_recv.c
> +++ b/net/rds/ib_recv.c
> @@ -949,6 +949,12 @@ 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,
> +				  "fragment shorter than header-declared length; forcing reconnect\n");
> +		goto done;
> +	}
> +
>  	list_add_tail(&recv->r_frag->f_item, &ibinc->ii_frags);
>  	recv->r_frag = NULL;
>  
> @@ -1004,7 +1010,12 @@ void rds_ib_recv_cqe_handler(struct rds_ib_connection *ic,
>  	 * event is processed.
>  	 */
>  	if (wc->status == IB_WC_SUCCESS) {
> -		rds_ib_process_recv(conn, recv, wc->byte_len, state);
> +		if (wc->opcode != IB_WC_RECV)
> +			rds_ib_conn_error(conn,
> +					  "recv completion had unexpected opcode %u, disconnecting and reconnecting\n",
> +					  wc->opcode);
> +		else
> +			rds_ib_process_recv(conn, recv, wc->byte_len, state);
>  	} else {
>  		/* We expect errors as the qp is drained during shutdown */
>  		if (rds_conn_up(conn) || rds_conn_connecting(conn))
> 
> base-commit: 72d3fcf802c45d00b300f25b848a93c3a2bd7c7e