From nobody Sat Oct 24 13:22:41 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 C906B5476F1; Tue, 13 Oct 2026 20:12:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1791922369; cv=none; b=bq2LHG6rRhldX1NlSIohi0IhPbjEWSFFV/0HNZLAk8Z4FnuYghS3XJ2pcj0pXcu6gxnvTyEWuB+hE9k+632BM+h4bsKZ+IqUx9lOF3KhCpY7eWeQMPxpW6+nf1/aGDQM/BIgS9cT5hzk4jXZqRshl+sfAi7+KVy0SHXX7bMgzaI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1791922369; c=relaxed/simple; bh=xNb4HR1SSJK+4fbIYQIcFAbHNxwUdPjA4ionyGzqQGA=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=feyF4FcwemYEFa/LwD4WyiyrSXQpxeY3LnywH24sC5z06X1TLrX7QV7DHYQ/xm4CuIPynznBfTi4rIWDNHIyrYTSYBfU8uMgIB3vi0x4spTmtVrOfSkOyJzjSbpQRw/MKj4QmWKvB48gbVjSfNbyiP93lkG8DWUqOYKWbUQFthE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=GRwnErIZ; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="GRwnErIZ" Received: by smtp.kernel.org (Postfix) with ESMTPS id 7317AC2BCF4; Tue, 13 Oct 2026 20:12:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1791922369; bh=xNb4HR1SSJK+4fbIYQIcFAbHNxwUdPjA4ionyGzqQGA=; h=From:Date:Subject:References:In-Reply-To:To:Cc:Reply-To:From; b=GRwnErIZQiDrwWon6iRPSkWGd/oOf0ka3GxsJwih81m3psGcCDcXcSDn9M8/hrdt0 5GksBFkCmHxmmVdBX3w12MDw6Cm0qSO/8XcpOSBBP9GeZ4rEpgDwNrkz238vPA6D8e QO188rh8Oc2SM7AscO6esNHKqQY0TYgG0aVGteK1CdUEydZ+s+pDcxAJtvkMoewwUs 0l9k+kdBpXl7VhLQw27dr1WbtVmRdOS4R/018ixuUyYJPkJUn+fyKIRdvBk3YlETLX 2VPpv3Q5X3NTKKaWETZB57LNhwDg3G9VvEvCWDDXEr7N52If/rbeoFxo1GFuqyPdT4 FnhcNtFD630RQ== Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4C6FCCC6B12; Tue, 13 Oct 2026 20:12:49 +0000 (UTC) From: Bryam Vargas via B4 Relay Date: Tue, 13 Oct 2026 15:12:48 -0500 Subject: [PATCH net v7 1/4] net/smc: bound the wire-controlled producer cursor to the RMB Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20261013-b4-disp-f345196c-v7-1-ef3dddfbfa68@proton.me> References: <20261013-b4-disp-f345196c-v7-0-ef3dddfbfa68@proton.me> In-Reply-To: <20261013-b4-disp-f345196c-v7-0-ef3dddfbfa68@proton.me> To: "D. Wythe" , Jakub Kicinski , Paolo Abeni , Eric Dumazet , Dust Li , Mahanta Jambigi , Sidraya Jayagond , "David S. Miller" Cc: netdev@vger.kernel.org, Simon Horman , linux-kernel@vger.kernel.org, Wenjia Zhang , Tony Lu , linux-s390@vger.kernel.org, Guangguan Wang , Ursula Braun , linux-rdma@vger.kernel.org, Stefan Raspl , Hidayath Khan , Wen Gu X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=ed25519-sha256; t=1791922368; l=3046; i=hexlabsecurity@proton.me; s=default; h=from:subject:message-id; bh=9ja5JoT+O2VUsGXhvlsOd1Bx55l6YLeZkBRApwlhPSc=; b=rVYcu4i4oTyDRLtwHGtEjq2DjTHtK80IgFrn7b5X+ZoM5nM630eyXVJvGwmEfj8XrGkYIgnGW bvnALUCmsOTBeGkQlTjfaeEVmS5YcBhwnF2hIsCNki/nNTHkpT5yDEp X-Developer-Key: i=hexlabsecurity@proton.me; a=ed25519; pk=xw1AhCtQdvuoQc+bOQIYy9o8G++cp4/VniI2G/tc3G8= X-Endpoint-Received: by B4 Relay for hexlabsecurity@proton.me/default with auth_id=893 X-Original-From: Bryam Vargas Reply-To: hexlabsecurity@proton.me From: Bryam Vargas smcr_cdc_msg_to_host() and smcd_cdc_msg_to_host() import the peer's producer cursor from the wire into conn->local_rx_ctrl.prod without bounding it to the RMB. smc_cdc_handle_urg_data_arrival() then uses its count as a raw index into the RMB, so a producer cursor past rmb_desc->len makes the receive tasklet read past the RMB, and recv(MSG_OOB) hands that byte to the application. Bound the producer cursor count to rmb_desc->len when it comes off the wire, for SMC-R and SMC-D. Leave the consumer cursor alone: it indexes the peer's RMB, which can be larger than ours, so clamping it to our RMB would under-credit peer_rmbe_space and could stall sending to that peer. Conforming peers are unaffected. Fixes: de8474eb9d50 ("net/smc: urgent data support") Cc: stable@vger.kernel.org Signed-off-by: Bryam Vargas Reviewed-by: Dust Li Reviewed-by: Sidraya Jayagond --- net/smc/smc_cdc.h | 17 ++++++++++++++--- 1 file changed, 14 insertions(+), 3 deletions(-) diff --git a/net/smc/smc_cdc.h b/net/smc/smc_cdc.h index 696cc11f2303..4d630a305118 100644 --- a/net/smc/smc_cdc.h +++ b/net/smc/smc_cdc.h @@ -221,7 +221,8 @@ static inline void smc_host_msg_to_cdc(struct smc_cdc_m= sg *peer, =20 static inline void smc_cdc_cursor_to_host(union smc_host_cursor *local, union smc_cdc_cursor *peer, - struct smc_connection *conn) + struct smc_connection *conn, + int max_count) { union smc_host_cursor temp, old; union smc_cdc_cursor net; @@ -235,6 +236,12 @@ static inline void smc_cdc_cursor_to_host(union smc_ho= st_cursor *local, if ((old.wrap =3D=3D temp.wrap) && (old.count > temp.count)) return; + /* The urgent path uses the producer count as a raw index into our + * RMB, so bound it. max_count =3D=3D 0 leaves the consumer cursor alone: + * it indexes the peer's RMB, which can be larger than ours. + */ + if (max_count && temp.count > max_count) + temp.count =3D max_count; smc_curs_copy(local, &temp, conn); } =20 @@ -246,8 +253,9 @@ static inline void smcr_cdc_msg_to_host(struct smc_host= _cdc_msg *local, local->len =3D peer->len; local->seqno =3D ntohs(peer->seqno); local->token =3D ntohl(peer->token); - smc_cdc_cursor_to_host(&local->prod, &peer->prod, conn); - smc_cdc_cursor_to_host(&local->cons, &peer->cons, conn); + smc_cdc_cursor_to_host(&local->prod, &peer->prod, conn, + conn->rmb_desc->len); + smc_cdc_cursor_to_host(&local->cons, &peer->cons, conn, 0); local->prod_flags =3D peer->prod_flags; local->conn_state_flags =3D peer->conn_state_flags; } @@ -260,6 +268,9 @@ static inline void smcd_cdc_msg_to_host(struct smc_host= _cdc_msg *local, =20 temp.wrap =3D peer->prod.wrap; temp.count =3D peer->prod.count; + /* as in smc_cdc_cursor_to_host(): bound prod, not cons */ + if (temp.count > conn->rmb_desc->len) + temp.count =3D conn->rmb_desc->len; smc_curs_copy(&local->prod, &temp, conn); =20 temp.wrap =3D peer->cons.wrap; --=20 2.56.0 From nobody Sat Oct 24 13:22:41 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 C914E5476F4; Tue, 13 Oct 2026 20:12:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1791922369; cv=none; b=FcPx8fe806gnkjjMbX54NkTrAaTjql+NEQ8FNMA2CnduAdmy15/YhkvDugbxhCGl2Wwjz4lwUAPSaNdbIwPGHedcWQOWEsG4/zet4MKgQBo+HZKKMtBUuOpfG0wRlWi1AhrCdfR2KKnV79I1+rTEtWj3tHDcPiH6Vd7aD6Rnnjg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1791922369; c=relaxed/simple; bh=xNUgH9Tz/TyF353OD1griDO1lTIRm5Atd24tjf+OZhw=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=D0kFpwVimh9ww4o34luZ9sgF1nvKHktcj+a0S0x9QBrcGBjl+nBbFA53JIht6qe0oWgRMSfhV9ANdPEgEcaYNa6t3msGSyoxaGZB5RgJ8bopmFYnysjpfnoPIo3e77bIKD0hx/afAIzkeEgCKs+g0VkSk3iYVGh/ZIEcd5V6koo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=UPTItYek; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="UPTItYek" Received: by smtp.kernel.org (Postfix) with ESMTPS id 84344C2BCFF; Tue, 13 Oct 2026 20:12:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1791922369; bh=xNUgH9Tz/TyF353OD1griDO1lTIRm5Atd24tjf+OZhw=; h=From:Date:Subject:References:In-Reply-To:To:Cc:Reply-To:From; b=UPTItYek7b+P05gGcbIEyPaRfb65BiNjCYnMhxJC1WgciupyB/K2f9vbgxr0e2fdS QaVn4xAm69CG60ZEuKKrrEvc7snPZTIX1+MncIW0f/INfMlD5Y9nM2Pmr2sSwGLAmY qhl6JWpyhOTzr9fSkxg3JLJHSlbFf1jlECiJ4xrjgFhBWMLnQZDQsPzHWsXFIpYF+q Mia4X0fDWGveNrI/XonWP8G+YBSgggk2YIvWdfY8WSYFh1QaARAErIDgayI8nwdPpG AaN+r8PZjlQWExEESt6eE7fEwhVGgHo4JcHfIrCLQC3shqftBCaAbftla+75dNw3tx c/utlSd2KkcAQ== Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id 657A0CC6B1C; Tue, 13 Oct 2026 20:12:49 +0000 (UTC) From: Bryam Vargas via B4 Relay Date: Tue, 13 Oct 2026 15:12:49 -0500 Subject: [PATCH net v7 2/4] net/smc: bound the receive length to the RMB Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20261013-b4-disp-f345196c-v7-2-ef3dddfbfa68@proton.me> References: <20261013-b4-disp-f345196c-v7-0-ef3dddfbfa68@proton.me> In-Reply-To: <20261013-b4-disp-f345196c-v7-0-ef3dddfbfa68@proton.me> To: "D. Wythe" , Jakub Kicinski , Paolo Abeni , Eric Dumazet , Dust Li , Mahanta Jambigi , Sidraya Jayagond , "David S. Miller" Cc: netdev@vger.kernel.org, Simon Horman , linux-kernel@vger.kernel.org, Wenjia Zhang , Tony Lu , linux-s390@vger.kernel.org, Guangguan Wang , Ursula Braun , linux-rdma@vger.kernel.org, Stefan Raspl , Hidayath Khan , Wen Gu X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=ed25519-sha256; t=1791922368; l=4891; i=hexlabsecurity@proton.me; s=default; h=from:subject:message-id; bh=WO6JE1/adE/4enEj6zr53PT4E+4sxDNOtNP9RW/QtGU=; b=dJVEzgAj1vgolb37GpaxkDKmrT2lJeSMcUxhHDJ/6AsC9BignokEKKt91HpeoyxMAnpWzXD07 65nGiJJuINTBETl0aMOCbW8s8r5Y1/C1V4xpxFMSFa44axF+m6vvEpz X-Developer-Key: i=hexlabsecurity@proton.me; a=ed25519; pk=xw1AhCtQdvuoQc+bOQIYy9o8G++cp4/VniI2G/tc3G8= X-Endpoint-Received: by B4 Relay for hexlabsecurity@proton.me/default with auth_id=893 X-Original-From: Bryam Vargas Reply-To: hexlabsecurity@proton.me From: Bryam Vargas smc_rx_recvmsg() sizes the copy from bytes_to_rcv and starts it past the bytes MSG_PEEK or splice() already took. A forged producer cursor drives bytes_to_rcv past the RMB or negative, and with a conforming peer it drops below the peeked count when a MSG_PEEK|MSG_WAITALL reader sleeps while another recv() consumes what it peeked. Either way the copy reads past the RMB into the reader's buffer: the second chunk runs long, or the start offset leaves the RMB, as smc_curs_add() wraps only once. Make smc_rx_data_available() report at most what fits in the RMB behind the peeked and spliced bytes, never a negative count, and use it for the copy and the wait predicates. Cache the RMB length for the unlocked wait, and drop released bytes from splice_pending before the consumer cursor moves past them, so no reader counts them twice. Fixes: 952310ccf2d8 ("smc: receive data from RMBE") Fixes: 9014db202cb7 ("smc: add support for splice()") Fixes: a4b6539038c1 ("net/smc: fix data error when recvmsg with MSG_PEEK fl= ag") Reported-by: Sashiko Closes: https://sashiko.dev/#/patchset/20261008-b4-disp-f7cd3d96-v6-0-fba61= 6c0920c@proton.me?part=3D2 Closes: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20261008-b4-dis= p-f7cd3d96-v6-0-fba616c0920c%40proton.me?part=3D2 Closes: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20261008-b4-dis= p-f7cd3d96-v6-0-fba616c0920c%40proton.me?part=3D1 Cc: stable@vger.kernel.org Signed-off-by: Bryam Vargas --- The wait predicates run unlocked, where a link group termination may already have freed rmb_desc, hence the cached length. With the old splice_pending order, a reader that took the lock between the cursor update and the drop counted the bytes twice, and the next splice() returned stale bytes in place of unread data. 1/4 bounds the producer count, but wrap bumps still grow bytes_to_rcv past the RMB (see the cover). --- net/smc/smc.h | 3 +++ net/smc/smc_core.c | 1 + net/smc/smc_rx.c | 7 ++++++- net/smc/smc_rx.h | 11 ++++++++++- 4 files changed, 20 insertions(+), 2 deletions(-) diff --git a/net/smc/smc.h b/net/smc/smc.h index 427b6d63b993..d4325a0a8fd8 100644 --- a/net/smc/smc.h +++ b/net/smc/smc.h @@ -203,6 +203,9 @@ struct smc_connection { * rmbe */ int rtoken_idx; /* idx to peer RMB rkey/addr */ + int rmb_len; /* rmb_desc->len, still valid + * after rmb_desc is freed + */ =20 struct smc_buf_desc *sndbuf_desc; /* send buffer descriptor */ struct smc_buf_desc *rmb_desc; /* RMBE descriptor */ diff --git a/net/smc/smc_core.c b/net/smc/smc_core.c index 9974149659c2..8829517299de 100644 --- a/net/smc/smc_core.c +++ b/net/smc/smc_core.c @@ -2503,6 +2503,7 @@ static int __smc_buf_create(struct smc_sock *smc, boo= l is_smcd, bool is_rmb) =20 if (is_rmb) { conn->rmb_desc =3D buf_desc; + conn->rmb_len =3D buf_desc->len; conn->rmbe_size_comp =3D bufsize_comp; smc->sk.sk_rcvbuf =3D bufsize * 2; atomic_set(&conn->bytes_to_rcv, 0); diff --git a/net/smc/smc_rx.c b/net/smc/smc_rx.c index 197fddc6271f..c968ac874d8b 100644 --- a/net/smc/smc_rx.c +++ b/net/smc/smc_rx.c @@ -118,15 +118,20 @@ static void smc_rx_pipe_buf_release(struct pipe_inode= _info *pipe, struct smc_connection *conn =3D &priv->smc->conn; struct smc_sock *smc =3D priv->smc; struct sock *sk =3D &smc->sk; + bool drained; =20 lock_sock(sk); if (conn->freed) { release_sock(sk); goto out; } + /* drop the released bytes from splice_pending before cons moves + * past them, so no reader counts them twice + */ + drained =3D atomic_sub_and_test(priv->len, &conn->splice_pending); smc_rx_update_cons(smc, priv->len); release_sock(sk); - if (atomic_sub_and_test(priv->len, &conn->splice_pending)) + if (drained) smc_rx_wake_up(sk); out: kfree(priv); diff --git a/net/smc/smc_rx.h b/net/smc/smc_rx.h index 994f5e42d1ba..6bf44e3cc33a 100644 --- a/net/smc/smc_rx.h +++ b/net/smc/smc_rx.h @@ -25,7 +25,16 @@ int smc_rx_wait(struct smc_sock *smc, long *timeo, size_= t peeked, int (*fcrit)(struct smc_connection *conn, size_t baseline)); static inline int smc_rx_data_available(struct smc_connection *conn, size_= t peeked) { - return atomic_read(&conn->bytes_to_rcv) - peeked; + int avail =3D atomic_read(&conn->bytes_to_rcv); + + /* bytes_to_rcv follows the peer's producer cursor and can be past + * the RMB or negative. Report no more than fits in the RMB behind the + * bytes already spliced or peeked. Compare before subtracting: near + * INT_MIN, avail - peeked wraps. This also runs unlocked, possibly + * after rmb_desc was freed, hence rmb_len. + */ + avail =3D min(avail, conn->rmb_len - atomic_read(&conn->splice_pending)); + return avail > (int)peeked ? avail - (int)peeked : 0; } =20 #endif /* SMC_RX_H */ --=20 2.56.0 From nobody Sat Oct 24 13:22:41 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 DA1105476FD; Tue, 13 Oct 2026 20:12:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1791922369; cv=none; b=XXozII/1ga+UgKoX9gMVJhmjiKLLosfEttCEZJuUTbyi70/5YBS8gSywRYDmCw+8xWH+enZUIeiY8LmEXHaTVjQ5WqJFjPKKvRYtW0S2VRTlUdbVbl0kdOyp4bHWOKDrX4rdK/letDVQSU7pKeGGiRCAynIkFe1IDBuolBj6A70= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1791922369; c=relaxed/simple; bh=Lnl0XF0TzVvqTKPExTtZgk/B+UiY8r13RpWybMJhiPw=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=rtBfnY7aj16nO9aUOYjui/xUXOaUB+fHiYqlpth00GGVy/PLSW05nwLQ2+0MjtmSN9rHvjU+JRHPzlt7zdg0JTE/d0z/nee6hvYJPqBzBOPmeE0MF/Uh6E1A5bcCRAI+0w7S+GY27dvsWauH/mMa7b+6a4YqobGkr0q0QdH88As= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=GnOYDFpj; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="GnOYDFpj" Received: by smtp.kernel.org (Postfix) with ESMTPS id 9F4F6C4AF0B; Tue, 13 Oct 2026 20:12:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1791922369; bh=Lnl0XF0TzVvqTKPExTtZgk/B+UiY8r13RpWybMJhiPw=; h=From:Date:Subject:References:In-Reply-To:To:Cc:Reply-To:From; b=GnOYDFpjhvSyr3njOPOq8O4vq7VeLn/PamIVQT88WkeWfJMK/H+I3U+JIzEqA3RLN jS6y79JeJqKCUcrTdfzZeEYHInSCLs3lM9w5jy3Oa5q6YyIhTXOzQv4DVDNjdYgUE2 IvzcIshWzFv9nwBJ8VrQLZ/k9ZwbEjtXe8lONh6zrvXAWmE+Wjd6AqYzAPSfz1MiV1 8os/BiPWmPdUxrxIIgaLwmVeAVztzSbFcErLZYHQm+ZZsAy4OyrCpkNOMpM92K6AaY br1q9ji6HPE/BLFo68C28e2O41nMkdN3yQ249hWi3dSL3hjYXuHQ0kwQrkvkaFrq0+ x9JWbdlW5EKcg== Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id 83121CC6B1A; Tue, 13 Oct 2026 20:12:49 +0000 (UTC) From: Bryam Vargas via B4 Relay Date: Tue, 13 Oct 2026 15:12:50 -0500 Subject: [PATCH net v7 3/4] net/smc: bound the send length to the send buffer in smc_tx_sendmsg() Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20261013-b4-disp-f345196c-v7-3-ef3dddfbfa68@proton.me> References: <20261013-b4-disp-f345196c-v7-0-ef3dddfbfa68@proton.me> In-Reply-To: <20261013-b4-disp-f345196c-v7-0-ef3dddfbfa68@proton.me> To: "D. Wythe" , Jakub Kicinski , Paolo Abeni , Eric Dumazet , Dust Li , Mahanta Jambigi , Sidraya Jayagond , "David S. Miller" Cc: netdev@vger.kernel.org, Simon Horman , linux-kernel@vger.kernel.org, Wenjia Zhang , Tony Lu , linux-s390@vger.kernel.org, Guangguan Wang , Ursula Braun , linux-rdma@vger.kernel.org, Stefan Raspl , Hidayath Khan , Wen Gu X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=ed25519-sha256; t=1791922368; l=2633; i=hexlabsecurity@proton.me; s=default; h=from:subject:message-id; bh=lUNbhzoLihltUOk3ECDO1KVY6cuHiA2nFGBtBf+62Cw=; b=jBsmKMJF65B6v5ECU9jhYs9tNrifsJ6m5nxP3hCM8A6y28WYuNNyFQzcThBMat0T39Q/yDNFJ 7T7FooC6YHmDPp8YBC6Ik2CWrgAoBgFK8GJzkoLXJyzuvHurRBoFaAo X-Developer-Key: i=hexlabsecurity@proton.me; a=ed25519; pk=xw1AhCtQdvuoQc+bOQIYy9o8G++cp4/VniI2G/tc3G8= X-Endpoint-Received: by B4 Relay for hexlabsecurity@proton.me/default with auth_id=893 X-Original-From: Bryam Vargas Reply-To: hexlabsecurity@proton.me From: Bryam Vargas conn->sndbuf_space can run past the send buffer. After an SMC-R link failover, a late completion from the old link can move tx_curs_fin back, and the next completion credits the same bytes again; across the ring end, smc_curs_diff() credits the step back itself as more than a whole ring, so even with a conforming peer sndbuf_space can reach three times the buffer. The failover catch-up and SMC-D DMB merge (only the loopback device today) also credit it from the peer's consumer cursor without a bound. smc_tx_sendmsg() takes it as the write space, and the second chunk of its copy writes past the send buffer. Clamp writespace, which sizes the copy, to sndbuf_desc->len, negative values included, so the copy stays in the send buffer. Fixes: c6f02ebeea3a ("net/smc: switch connections to alternate link") Fixes: cc0ab806fc52 ("net/smc: adapt cursor update when sndbuf and peer DMB= are merged") Cc: stable@vger.kernel.org Signed-off-by: Bryam Vargas Reviewed-by: Dust Li Reviewed-by: Sidraya Jayagond --- This keeps the copy inside the send buffer but does not undo the over-credit, so after such a failover send() can still overwrite data in the buffer that the peer has not received yet (by inspection; not tested). Fixing the credit in smc_cdc_tx_handler() needs a cursor compare that survives the u16 wrap rollover, which smc_curs_comp() does not do, so it is left out here. A negative value maps to len, not 0, since 0 would make the send loop spin. --- net/smc/smc_tx.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/net/smc/smc_tx.c b/net/smc/smc_tx.c index 3144b4b1fe29..58d9dfdcdf33 100644 --- a/net/smc/smc_tx.c +++ b/net/smc/smc_tx.c @@ -233,6 +233,14 @@ int smc_tx_sendmsg(struct smc_sock *smc, struct msghdr= *msg, size_t len) /* initialize variables for 1st iteration of subsequent loop */ /* could be just 1 byte, even after smc_tx_wait above */ writespace =3D atomic_read(&conn->sndbuf_space); + /* sndbuf_space can be out of range: late completions of an + * old SMC-R link credit it again after a failover, and with + * SMC-D DMB merge it follows the peer's consumer cursor. + * Bound writespace, which sizes the copy; a negative value + * would become huge in the size_t min_t() below. + */ + if (writespace < 0 || writespace > conn->sndbuf_desc->len) + writespace =3D conn->sndbuf_desc->len; /* not more than what user space asked for */ copylen =3D min_t(size_t, send_remaining, writespace); /* determine start of sndbuf */ --=20 2.56.0 From nobody Sat Oct 24 13:22:41 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 F0519548548; Tue, 13 Oct 2026 20:12:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1791922370; cv=none; b=u79C8bbV6eqolSh8sAnBFx9vebN9nKcKGiEfxkJO/QZsIVRD7UAwtmo4P1FPciek0961adENYcMnwIZe2sQBpG9ymBLrH68+AAPkWeRAVkipYvxl8+MV0Jy+Tdjxd2AEXkedvbVpoUC6uwW/9QytKyMHojbwv3lm2IF/pn3cstA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1791922370; c=relaxed/simple; bh=IXCu3AOkyIWIO2ajrw/IoCAtKoPvKD6T9k2uhXy3DPg=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=c80IZib19djSWSSpbHmNz6Y0+8uGBDHzHqZgCj1+5KSqT/Vsb7B/nSPPWIS0nRqXJEIFtjUuE3xZ5Y1MbVAtB/WK0MTo8IyiaqXoLF1WoL/ioJfR3xkKeYmu5PkNLEh7tLMqgAS5bEt0jC8D2Qpm3sb5SJznOIdDmngUbXNUovQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=LCdfTkRX; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="LCdfTkRX" Received: by smtp.kernel.org (Postfix) with ESMTPS id B10BCC32782; Tue, 13 Oct 2026 20:12:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1791922369; bh=IXCu3AOkyIWIO2ajrw/IoCAtKoPvKD6T9k2uhXy3DPg=; h=From:Date:Subject:References:In-Reply-To:To:Cc:Reply-To:From; b=LCdfTkRXrhdf6ssojJmdvnZqHWOq/M7ok5jbknRWQq/8fwPaQUGw4dXYtR5OeIsre 70YOSCq6PUfN11VkSFUZqShM4AVYYQ5IVLAL/Hwj+VpdeikgcmU1r1Jm0rqq00sDsV iG3tWokQCPJTFYjSRUpKoDc5Lq7x3wWJ5cUp81CaGLP8vQvKN3PfkL+tEQ8toaaAAz EVYxW/GlrevQRzLxAALpnvAK5Bv1eKa1wf+sGvX+p71alPLDBTgy4p3YySWeoxt/+C vb7WiarRbj7TDSYORaHq7fttJ0XHbAAoeZLAFV1r6jV6xKybq3+sjPzROKQkwhC1c7 GiFkJwQxqG0nA== Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9BDE4CC6B19; Tue, 13 Oct 2026 20:12:49 +0000 (UTC) From: Bryam Vargas via B4 Relay Date: Tue, 13 Oct 2026 15:12:51 -0500 Subject: [PATCH net v7 4/4] net/smc: bound the link failover cursor advance to the send buffer Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20261013-b4-disp-f345196c-v7-4-ef3dddfbfa68@proton.me> References: <20261013-b4-disp-f345196c-v7-0-ef3dddfbfa68@proton.me> In-Reply-To: <20261013-b4-disp-f345196c-v7-0-ef3dddfbfa68@proton.me> To: "D. Wythe" , Jakub Kicinski , Paolo Abeni , Eric Dumazet , Dust Li , Mahanta Jambigi , Sidraya Jayagond , "David S. Miller" Cc: netdev@vger.kernel.org, Simon Horman , linux-kernel@vger.kernel.org, Wenjia Zhang , Tony Lu , linux-s390@vger.kernel.org, Guangguan Wang , Ursula Braun , linux-rdma@vger.kernel.org, Stefan Raspl , Hidayath Khan , Wen Gu X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=ed25519-sha256; t=1791922368; l=2755; i=hexlabsecurity@proton.me; s=default; h=from:subject:message-id; bh=WmGU8zUppN7BH0rV8o+Estl5Zae56D3SssXqw8plQEU=; b=A3NOyHr0oJ7D6eONfsU+V5uBJSVuv/KU5E1/NhUJkpSNObgkRkpdqMrywMz1DlFzcm+ftTPRW R+LFpRK7IhkD9tDv89mYG47MaUgCRO13Rs+dzCN+JZvvqMuSkxEY/Me X-Developer-Key: i=hexlabsecurity@proton.me; a=ed25519; pk=xw1AhCtQdvuoQc+bOQIYy9o8G++cp4/VniI2G/tc3G8= X-Endpoint-Received: by B4 Relay for hexlabsecurity@proton.me/default with auth_id=893 X-Original-From: Bryam Vargas Reply-To: hexlabsecurity@proton.me From: Bryam Vargas On SMC-R link failover, smc_switch_cursor() rewinds the send and producer cursors to their values at the last completed CDC send, then advances them by however far the peer's consumer cursor is ahead. That cursor comes from the wire, so a forged one adds an arbitrary amount to sndbuf_space and to the cursors. smc_curs_add() wraps them only once, so the next RDMA write can take its source past the send buffer and its destination past the peer's RMB. A conforming peer keeps its cursor count inside its RMB and cannot consume past the data in the send buffer. Advance only for such a count, and no further than tx_curs_prep. The pre-failover tx_curs_sent cannot be the bound: an earlier failover may have rewound it below the peer's cursor. Fixes: c6f02ebeea3a ("net/smc: switch connections to alternate link") Cc: stable@vger.kernel.org Signed-off-by: Bryam Vargas --- Bounding the copy in smc_tx_sendmsg() (3/4) does not cover this: the RDMA write takes its offsets from the cursors. --- net/smc/smc_core.c | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/net/smc/smc_core.c b/net/smc/smc_core.c index 8829517299de..36aee89e5f5f 100644 --- a/net/smc/smc_core.c +++ b/net/smc/smc_core.c @@ -1034,7 +1034,7 @@ static int smc_switch_cursor(struct smc_sock *smc, st= ruct smc_cdc_tx_pend *pend, struct smc_wr_buf *wr_buf) { struct smc_connection *conn =3D &smc->conn; - union smc_host_cursor cons, fin; + union smc_host_cursor cons, fin, prep; int rc =3D 0; int diff; =20 @@ -1043,12 +1043,18 @@ static int smc_switch_cursor(struct smc_sock *smc, = struct smc_cdc_tx_pend *pend, /* set prod cursor to old state, enforce tx_rdma_writes() */ smc_curs_copy(&conn->local_tx_ctrl.prod, &fin, conn); smc_curs_copy(&cons, &conn->local_rx_ctrl.cons, conn); + smc_curs_copy(&prep, &conn->tx_curs_prep, conn); =20 - if (smc_curs_comp(conn->peer_rmbe_size, &cons, &fin) < 0) { + if (cons.count < conn->peer_rmbe_size && + smc_curs_comp(conn->peer_rmbe_size, &cons, &fin) < 0) { /* cons cursor advanced more than fin, and prod was set - * fin above, so now prod is smaller than cons. Fix that. + * fin above, so now prod is smaller than cons. cons comes + * off the wire: catch up only for a count inside the peer's + * RMB and no further than the data in the send buffer. */ - diff =3D smc_curs_diff(conn->peer_rmbe_size, &fin, &cons); + diff =3D min(smc_curs_diff(conn->peer_rmbe_size, &fin, &cons), + smc_curs_diff(conn->sndbuf_desc->len, + &conn->tx_curs_sent, &prep)); smc_curs_add(conn->sndbuf_desc->len, &conn->tx_curs_sent, diff); smc_curs_add(conn->sndbuf_desc->len, --=20 2.56.0