From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3993D134CF; Wed, 17 Jun 2026 18:25:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781720746; cv=none; b=JmpNidqGdgbXbe2qAK6FXTtr1hHKNUVGbEuUeNFDKyYU5PHsBS7Iajrn+dHKHyvzniCq3s5jU9iuwHeoXKfyCJ20hOxDTBPt+tgHzLdFfqAclG5SE2DuKg+ccB90KpxEJ2AIXgH8wsptEC2reTc+iGVBtZpyQTUwDBxvvtyerT0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781720746; c=relaxed/simple; bh=Insbb4m5VY8Bj9kG0mK0lWc0V7QajkhFlxTizRJpbFo=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=rzZxJB6aLYtHHda1Xm8X8ERAXEqKMJwywFgmJOWrXTXVZIEqCspNAFMXwcsAjHGeOq1KRTOwLmXgo6hDypOQN2X5TWcthTkxPloxeNYv5XoWyiGxaBkdggK9t4shV6Kjm06dEYRuGca1rhfIPifZL5uQNzF4R3hxk4/o4eZf43c= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=C8XuDcHh; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="C8XuDcHh" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 519561F000E9; Wed, 17 Jun 2026 18:25:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1781720744; bh=gUzfZHIg0OEVhvJFDOxsMxKZengHRyuStreBfVTFXyA=; h=Subject:From:To:Cc:Date:In-Reply-To:References; b=C8XuDcHhosoJzRD2ckESYUaPf0+vt3r9mhO8ocToscSWELWHFm0BC/IFhVlvGrKPB kji8yuSt4/QY4XtymobNK0zts/JPKxnx5DMlgfgl30PRLRsrYcs7M/Rh4R1tXvJDml 3+YzLxqAaMQWRhot11v0Q0VoGQYtF1di/70ctWNzIWd4mXgpl3LGS67zKL8d2Fm2FM CGGq/57b67x44zacmWROP1a+dpshW07bMFmaKMjf5p1KYVSdmz0CcOGaECbbnbOqAs CwF5H8ROTY9Ii8T5Niy+z0fS2txK4ZQ6tCbi7GVXyGeUN4knsr3rlrbui69qEIxA+Q puVntB5BRj57w== Message-ID: <2a86a6f10a402ce9e43bd6fd3915694112597170.camel@kernel.org> Subject: Re: [PATCH net-next v2] net: rds: check cmsg_len before reading rds_rdma_args in size pass From: Allison Henderson To: Michael Bommarito , "David S . Miller" , Jakub Kicinski , Paolo Abeni , Eric Dumazet Cc: Simon Horman , netdev@vger.kernel.org, linux-rdma@vger.kernel.org, rds-devel@oss.oracle.com, linux-kernel@vger.kernel.org Date: Wed, 17 Jun 2026 11:25:43 -0700 In-Reply-To: <20260617023146.2780077-1-michael.bommarito@gmail.com> References: <20260617023146.2780077-1-michael.bommarito@gmail.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.52.3-0ubuntu1.1 Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 On Tue, 2026-06-16 at 22:31 -0400, Michael Bommarito wrote: > rds_rm_size() handles RDS_CMSG_RDMA_ARGS after only CMSG_OK() and then > calls rds_rdma_extra_size(), which reads args->local_vec_addr and > args->nr_local without first checking that cmsg_len covers struct > rds_rdma_args. The other two RDS_CMSG_RDMA_ARGS consumers already guard > this: rds_rdma_bytes() in rds_sendmsg() and rds_cmsg_rdma_args() in > rds_cmsg_send() both reject cmsg_len < CMSG_LEN(sizeof(struct > rds_rdma_args)). Add the same check to rds_rm_size() so all three RDMA > args passes are consistent. >=20 > This is a consistency and hardening change with no behavioral effect for > well-formed senders and no reachable bug today: rds_rdma_bytes() runs > before rds_rm_size() in rds_sendmsg() and already rejects a short > RDS_CMSG_RDMA_ARGS, so the size pass is not reached with an undersized > cmsg. But rds_rm_size() reads the args independently of that earlier > pass, and nothing in rds_rm_size() itself records or enforces the > precondition, so a reader or a future refactor of the size pass cannot > tell the cmsg has already been length-checked. Applying the same > cmsg_len guard in all three RDS_CMSG_RDMA_ARGS consumers keeps that > invariant local to each and robust to reordering. >=20 > Assisted-by: Claude:claude-opus-4-8 > Signed-off-by: Michael Bommarito This looks good to me. Thanks for working on this. Reviewed-by: Allison Henderson Allison > --- > v2: > - Re-target net-next and drop the Fixes: tag and the stable Cc. This > is a consistency/hardening change, not a reachable bug: as Allison > Henderson noted, rds_rdma_bytes() runs before rds_rm_size() in > rds_sendmsg() and already rejects a short RDS_CMSG_RDMA_ARGS, so a > user cannot reach the rds_rm_size() read through sendmsg. > - Corrected the changelog: the two sibling guards are rds_rdma_bytes() > in rds_sendmsg() and rds_cmsg_rdma_args() in rds_cmsg_send(); the > former runs before, not after, rds_rm_size(). > - Dropped the KASAN/AF_RDS reachability framing. No code change from v1. > - v1: https://lore.kernel.org/all/20260614130725.2520842-1-michael.bomma= rito@gmail.com/ >=20 > net/rds/send.c | 2 ++ > 1 file changed, 2 insertions(+) >=20 > diff --git a/net/rds/send.c b/net/rds/send.c > index d8b14ff9d366b..6ca3192b1d8af 100644 > --- a/net/rds/send.c > +++ b/net/rds/send.c > @@ -967,6 +967,8 @@ static int rds_rm_size(struct msghdr *msg, int num_sg= s, > =20 > switch (cmsg->cmsg_type) { > case RDS_CMSG_RDMA_ARGS: > + if (cmsg->cmsg_len < CMSG_LEN(sizeof(struct rds_rdma_args))) > + return -EINVAL; > if (vct->indx >=3D vct->len) { > vct->len +=3D vct->incr; > tmp_iov =3D >=20 > base-commit: 5200f5f493f79f14bbdc349e402a40dfb32f23c8