Re: [rds-devel] [External] : Re: [PATCH net] RDS/IB: validate receive completion payload length

[Gerd Rausch]

Hi,

On 2026-10-06 18:13, Allison Henderson via rds-devel wrote:
> > --- 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;
> >  
How does forcing a reconnect help this situation?

After the reconnect, the sender submits the exact same (incorrect) message again,
which it kept in "cp_retrans".

Therefore, the exact same conditional triggers again.

All but the last fragment of an RDS/IB message are expected to be of RDS_FRAG_SIZE.

While there's no good protocol specification (to the best of my knowledge),
posting an insufficiently large message can be seen as protocol violation.

Therefore, apart from security concerns, the previous behavior of garbage-in / garbage-out
is IMO better than this behavior of just endlessly forcing a reconnect.

If there's a strong desire to address this issue, the sender should be
told to discard the message. A reconnect doesn't address this issue.

Thanks,

  Gerd