From nobody Fri Sep 25 20:48:29 2026 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 8EF5E549364; Tue, 8 Sep 2026 14:14:18 +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=1788876869; cv=none; b=ed9e2gWfZsbEzSIpsmBVx5YLipOyFTf5JUwvpRXwc78C47NokN1o+SrM4pHjWxUJfrlhNV/eApj2t2krHS5iz9KPAi1xYvKl6feSToFh8our1hEEEnSSLlv87sSq5Spdwx4YdOMS2H3ccxeg1AIy/+aU8vInnVNtB+SbBAqE0wM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788876869; c=relaxed/simple; bh=7draGfBDNZi29j/TLTT47mMEBWips5JH8cEIVxr4N7w=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=uVkf1+tenlNKw6EHcjA4v/Rg2Ak9hZA06cbd+QXvQogoYWgehHPGBOwhGnu1WY/FdIidnf060y/Rml9flGykJIyUgfIq07/WIP6JL9gmFyOuRVIk2rSBK9dwqxF9t3QDvlKSN6c1x7xAnASphNFQCiAf/RzH6ySUDRuPNXTaxzk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=oimtIBqS; 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="oimtIBqS" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5756E1F00A3D; Tue, 8 Sep 2026 14:14:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1788876857; bh=17seS13qk4JOZLGW6Qfu9f3yF9o8uUYcInlzEsS2S0Q=; h=From:Date:Subject:References:In-Reply-To:To:Cc; b=oimtIBqS+hSoh7HEKX9BPZIPL+CGGLW4BjgFSV08G7k+unaA6I02tz40CCPDVIaTn CK8336vcLSesjXe53Xtj1jruFMXBSVOXaTN7Ybd0UlHdYoHMNHev6reTOhUaUBYBlq P/mVStZNArpQNoBT08t9YXObdiaCIiDsDjej3+7THJ1bcatYHf4MAczwBLoBZq5VE0 5NDjnJ77om7NTz9no4uDXw4n5v9QAIEbPwd6giur2YOjd14albDyMaSudkrEw8W5sL cWFl685WM66HaRXaT+Yh05s3OalafYW8CZCwNdOaeYPEznE+k/u85akaI02SV4VsyH UtG/s/0CvJwvQ== From: "Matthieu Baerts (NGI0)" Date: Tue, 08 Sep 2026 16:07:06 +0200 Subject: [PATCH net v2 01/15] mptcp: do not reschedule the RTX timer for fallback sockets Precedence: bulk X-Mailing-List: mptcp@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20260908-net-mptcp-misc-fixes-7-3-rc1-v2-1-df1de70348b6@kernel.org> References: <20260908-net-mptcp-misc-fixes-7-3-rc1-v2-0-df1de70348b6@kernel.org> In-Reply-To: <20260908-net-mptcp-misc-fixes-7-3-rc1-v2-0-df1de70348b6@kernel.org> To: Mat Martineau , Geliang Tang , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman Cc: netdev@vger.kernel.org, mptcp@lists.linux.dev, linux-kernel@vger.kernel.org, "Matthieu Baerts (NGI0)" , stable@vger.kernel.org X-Mailer: b4 0.16.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=3878; i=matttbe@kernel.org; h=from:subject:message-id; bh=LyPa1XUh+30erF0yIMt1XvekC3KhkLs9mfYDTkKecY0=; b=owGbwMvMwCVWo/Th0Gd3rumMp9WSGLIWSKgFP56WuIHlfKra+m39Pw7+XHb1zMuncv/9GywTI q94uB1x6ShlYRDjYpAVU2SRbovMn/m8irfEy88CZg4rE8gQBi5OAZiItDHDH07Bi06hOawdG7pq Fct+X+pp8GTUO9H8rJ/TuefD2ess+xkZDhhKqT4UuNHsc/bXhJxjyX2fWJY5nWT8IheUFmcs+1y QGwA= X-Developer-Key: i=matttbe@kernel.org; a=openpgp; fpr=E8CB85F76877057A6E27F77AF6B7824F4269A073 From: Paolo Abeni On fallback socket the retrans timer is a quite convoluted no-op, but currently nothing prevents the MPTCP core to keep rescheduling it. Additionally gate RTX timer reset to the msk not being fallen back to TCP yet. To avoid adding multiple tests in fast-path, use a new flags bit for such condition. The RTX enable bit is clear at close time and set before the msk could start retransmitting, with a couple of caveats: - passive sockets inherit the bit from the listener msk; set the bit on such socket to avoid flipping it in the fast-path, even if the listener will obviously never retransmit. - while fastopening (MPTFO), mptcp_sendmsg_fastopen still ends-up calling mptcp_connect via tcp_sendmsg_fastopen -> __inet_stream_connect(ssk->sk_socket), and the first subflow's sk_socket points to the msk one. Fixes: b51f9b80c032 ("mptcp: introduce MPTCP retransmission timer") Cc: stable@vger.kernel.org Signed-off-by: Paolo Abeni Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) --- v2: - Sashiko noted that the 'RTX disabled' status is carried over across connect() failures, potentially to subsequent successful connect() or listen(). Explicitly control the RTX enabling status across the whole msk life-cycle. To make the code more straight forward switch the newly introduced flag semantic. --- net/mptcp/protocol.c | 13 ++++++++++--- net/mptcp/protocol.h | 1 + 2 files changed, 11 insertions(+), 3 deletions(-) diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c index e1f08f71cdb1..be59651e708e 100644 --- a/net/mptcp/protocol.c +++ b/net/mptcp/protocol.c @@ -95,6 +95,7 @@ bool __mptcp_try_fallback(struct mptcp_sock *msk, int fb_= mib) =20 msk->allow_subflows =3D false; set_bit(MPTCP_FALLBACK_DONE, &msk->flags); + clear_bit(MPTCP_RTX_ENABLED, &msk->flags); __MPTCP_INC_STATS(net, fb_mib); spin_unlock_bh(&msk->fallback_lock); return true; @@ -1084,13 +1085,14 @@ static bool mptcp_rtx_timer_pending(struct sock *sk) =20 static void mptcp_reset_rtx_timer(struct sock *sk) { + struct mptcp_sock *msk =3D mptcp_sk(sk); unsigned long tout; =20 - /* prevent rescheduling on close */ - if (unlikely(inet_sk_state_load(sk) =3D=3D TCP_CLOSE)) + /* Prevent rescheduling on close and in case of fallback. */ + if (!test_bit(MPTCP_RTX_ENABLED, &msk->flags)) return; =20 - tout =3D mptcp_sk(sk)->timer_ival; + tout =3D msk->timer_ival; sk_reset_timer(sk, &sk->mptcp_retransmit_timer, jiffies + tout); } =20 @@ -3323,6 +3325,9 @@ void mptcp_set_state(struct sock *sk, int state) * transition from TCP_SYN_RECV to TCP_CLOSE_WAIT. */ break; + case TCP_CLOSE: + clear_bit(MPTCP_RTX_ENABLED, &mptcp_sk(sk)->flags); + fallthrough; default: if (oldstate =3D=3D TCP_ESTABLISHED || oldstate =3D=3D TCP_CLOSE_WAIT) MPTCP_DEC_STATS(sock_net(sk), MPTCP_MIB_CURRESTAB); @@ -4141,6 +4146,7 @@ static int mptcp_connect(struct sock *sk, struct sock= addr_unsized *uaddr, if (IS_ERR(ssk)) return PTR_ERR(ssk); =20 + set_bit(MPTCP_RTX_ENABLED, &msk->flags); mptcp_set_state(sk, TCP_SYN_SENT); subflow =3D mptcp_subflow_ctx(ssk); #ifdef CONFIG_TCP_MD5SIG @@ -4288,6 +4294,7 @@ static int mptcp_listen(struct socket *sock, int back= log) goto unlock; } =20 + set_bit(MPTCP_RTX_ENABLED, &msk->flags); mptcp_set_state(sk, TCP_LISTEN); sock_set_flag(sk, SOCK_RCU_FREE); =20 diff --git a/net/mptcp/protocol.h b/net/mptcp/protocol.h index 87ccb84e9927..2b4c27426477 100644 --- a/net/mptcp/protocol.h +++ b/net/mptcp/protocol.h @@ -116,6 +116,7 @@ #define MPTCP_WORK_RTX 1 #define MPTCP_FALLBACK_DONE 2 #define MPTCP_WORK_CLOSE_SUBFLOW 3 +#define MPTCP_RTX_ENABLED 4 =20 /* MPTCP socket release cb flags */ #define MPTCP_PUSH_PENDING 1 --=20 2.55.0 From nobody Fri Sep 25 20:48:29 2026 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 174F354A7ED; Tue, 8 Sep 2026 14:14:23 +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=1788876870; cv=none; b=HDeaNeo+vGvQlJ3FTm40td+XvkXumsEZpeHt7xQJQ8WKXC3pHa8WDALbiMULFjFVVBq947jxxmoboSRnUwnAO8HHxE1ITxfHtJtlG2oxeGlPi75yPmiRCSYZhsC4EGJSphnhuO939xcWIUTuvvUnBqUvfePwtDFkA2X6sSkcSy8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788876870; c=relaxed/simple; bh=CDC/K2FJRHVAGcRgJXtSdI6Hc3vAAlafTF+wKI4l1nY=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=DLLbAc+CSc0k0wHT7JXRxQckfimXpHoT0LV7bO9oOU/DvARAfsn60gN5T7Y0O4vAp9JKhAOEK7M2OpGPcCjALbO6j/yW2ij+smsAHCGU7lfXc3R26/wQCHNmRQto+/KiHM/jeTwbQ8Kljy1Kwe8G90MmYY3aSD+HxCfZncROONk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Tcibpc6p; 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="Tcibpc6p" Received: by smtp.kernel.org (Postfix) with ESMTPSA id AD92A1F00A3E; Tue, 8 Sep 2026 14:14:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1788876859; bh=0oaYRQgH57DHWr6sOc46cwyYSafOI68a2pNXApHJ4u4=; h=From:Date:Subject:References:In-Reply-To:To:Cc; b=Tcibpc6ps1nIcgg86IfKX7uvEGmRiVA1BOcGsqYLXvWMlKSlvpUOt9eFJWlQkUfo9 yKkUbt+1kpgoMih3mT712MOhYlDfrUKUAa5qpiXFxP7VZykW7VRWIixEa9KyCZ/t9d gzzxR2d9Wf5N+JIhcwa12rDfK4L8dYf1yJjbXYGwkjCps8esiMb8uDSJUte2JzwVd6 ARxZIBpUEY6FZp9GA6vce+qPO6VJr9ggFbUoOsvkAxbRK3KRnFJgw5X4SYZgaiC28p REOtbkGongFU8pHddpJJlkyF/lYxxgAJeaRgmU/oBsGBZnLnX7b9YnfQotZvAkjYLn 493cmO5YBG2Sw== From: "Matthieu Baerts (NGI0)" Date: Tue, 08 Sep 2026 16:07:07 +0200 Subject: [PATCH net v2 02/15] mptcp: subflow: no need to copy thmac during ulp_clone Precedence: bulk X-Mailing-List: mptcp@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20260908-net-mptcp-misc-fixes-7-3-rc1-v2-2-df1de70348b6@kernel.org> References: <20260908-net-mptcp-misc-fixes-7-3-rc1-v2-0-df1de70348b6@kernel.org> In-Reply-To: <20260908-net-mptcp-misc-fixes-7-3-rc1-v2-0-df1de70348b6@kernel.org> To: Mat Martineau , Geliang Tang , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman Cc: netdev@vger.kernel.org, mptcp@lists.linux.dev, linux-kernel@vger.kernel.org, "Matthieu Baerts (NGI0)" , stable@vger.kernel.org, Florian Westphal X-Mailer: b4 0.16.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=1448; i=matttbe@kernel.org; h=from:subject:message-id; bh=CDC/K2FJRHVAGcRgJXtSdI6Hc3vAAlafTF+wKI4l1nY=; b=owGbwMvMwCVWo/Th0Gd3rumMp9WSGLIWSKizt+3eeEbIbVtl9FxHrf6lLJJzrHUbbkzw4U8+v 3+S9erHHaUsDGJcDLJiiizSbZH5M59X8ZZ4+VnAzGFlAhnCwMUpABMxn8bwP/HHhK3lx09pT1p6 iHmJ8PfLBZVCS0w5j/048Pn3i5mftToZGfbPlpjKqFLFrx3N1ZoZonnLxnmXH5990wudrwJPJNO i+QE= X-Developer-Key: i=matttbe@kernel.org; a=openpgp; fpr=E8CB85F76877057A6E27F77AF6B7824F4269A073 'thmac' is not used after that point. Indeed, subflow_ulp_clone() is called when the request on the passive side is over, so when the truncated HMAC is no longer needed. Note that in case of SYN cookies, thmac will not be initialised. So better to remove it to avoid a warning from debug tools like KMSAN for reading uninitialised data. Fixes: f296234c98a8 ("mptcp: Add handling of incoming MP_JOIN requests") Cc: stable@vger.kernel.org Reviewed-by: Geliang Tang Signed-off-by: Matthieu Baerts (NGI0) --- Cc: Florian Westphal Note: Peter Krystad's email address is bouncing. @Sashiko: yes request_bkup's initialisation is not fixed in this commit but in the next one, no need to complain about that: different Fixes tag... --- net/mptcp/subflow.c | 1 - 1 file changed, 1 deletion(-) diff --git a/net/mptcp/subflow.c b/net/mptcp/subflow.c index af81ad5e699d..01db7edce18a 100644 --- a/net/mptcp/subflow.c +++ b/net/mptcp/subflow.c @@ -2084,7 +2084,6 @@ static void subflow_ulp_clone(const struct request_so= ck *req, new_ctx->request_bkup =3D subflow_req->request_bkup; WRITE_ONCE(new_ctx->remote_id, subflow_req->remote_id); new_ctx->token =3D subflow_req->token; - new_ctx->thmac =3D subflow_req->thmac; =20 /* the subflow req id is valid, fetched via subflow_check_req() * and subflow_token_join_request() --=20 2.55.0 From nobody Fri Sep 25 20:48:29 2026 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 B3FBA5452A2; Tue, 8 Sep 2026 14:14:25 +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=1788876875; cv=none; b=PN/peoWs2Dceg9Ra9FuBbLBbymtD3d4HTsyZxTPA+Dz8SpgsReNB03O9PGZzTCl7NEF0LLPpFXE8injokkbxDFF35/BjNesFR6Ttycun5a4lDrQVJhEcZEWUWFNJCOHk7vlwdkp5vCkIXyxV4d5vPfMvaM9UbspPh18OpFnuMh8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788876875; c=relaxed/simple; bh=fxMH39EiXefslZTzlRWNigq/snXjgcnGUl/f/2XEJ3Y=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=pJ8MRnmAx7nGJTPWDqKUiUZgDSXKxxAz8K2PTMehEmkaIxavP3BynpZ4AhxV9AMGJ/8d1Cd1OXwJ/UgwZXAb02yiPjWkCRQI7PIsLb0yl/U1F9b/bTTLHdB/nGTyoKqWLu0Uomb/oc+ECTN8o+NTr9+J430QGgrBzxNPR/YTq7s= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=MnSBQRiG; 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="MnSBQRiG" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3579A1F00A3F; Tue, 8 Sep 2026 14:14:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1788876862; bh=fw3sAfr3TBuViXjJMX6QyiDIAVSnEhj3ZWxnrfrUtV4=; h=From:Date:Subject:References:In-Reply-To:To:Cc; b=MnSBQRiG8CnPZkipcwyFkfJhN995n7+p1AslPgPe6b96ftWKsKOc3DwEuzprpWSEa pipTrNZzrse4qOvqvOeGHgea1POz07Fl8lZjYvCO8njoEPmz1TXFP42Lu0GserqKBZ tVTadBamAOoXcxLc2+woO8I1vOMq6T6hdLzbabQamsR60RIFeKRzqfY2GjbNF9MQyq iH4mAmyi8tgIsrClCh4kHc51P182cHqo6NIpJG49PRD+VAt2aYps5N+W9N7lre67Yx k2igUU00k0CXNo1MvRE0fivrlLp4DOJIG+J7xqXnMyVFAO5vkMbQ2n19qb2vvfcdYv NkQyjOHyw6hDw== From: "Matthieu Baerts (NGI0)" Date: Tue, 08 Sep 2026 16:07:08 +0200 Subject: [PATCH net v2 03/15] mptcp: syncookies: remember the request backup flag Precedence: bulk X-Mailing-List: mptcp@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20260908-net-mptcp-misc-fixes-7-3-rc1-v2-3-df1de70348b6@kernel.org> References: <20260908-net-mptcp-misc-fixes-7-3-rc1-v2-0-df1de70348b6@kernel.org> In-Reply-To: <20260908-net-mptcp-misc-fixes-7-3-rc1-v2-0-df1de70348b6@kernel.org> To: Mat Martineau , Geliang Tang , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman Cc: netdev@vger.kernel.org, mptcp@lists.linux.dev, linux-kernel@vger.kernel.org, "Matthieu Baerts (NGI0)" , stable@vger.kernel.org X-Mailer: b4 0.16.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=1762; i=matttbe@kernel.org; h=from:subject:message-id; bh=fxMH39EiXefslZTzlRWNigq/snXjgcnGUl/f/2XEJ3Y=; b=owGbwMvMwCVWo/Th0Gd3rumMp9WSGLIWSGgIPnSbFmqr55UwVcvaqu6rgY+a9R+7fd/2Gl6YH DRf6kh+RykLgxgXg6yYIot0W2T+zOdVvCVefhYwc1iZQIYwcHEKwERCLjMyLA+YzGNotfernsMz EbXN15Q+7ki/nxrxuTfRwzxrWfm5JIb/AVuWqSrPrPfYs77UbpPAsYMtV5ZEl7f6tnip+3v5lv5 kBwA= X-Developer-Key: i=matttbe@kernel.org; a=openpgp; fpr=E8CB85F76877057A6E27F77AF6B7824F4269A073 Instead of using an uninitialised bit when copying the info in subflow_ulp_clone(). To fix this, no need to extend the join_entry structure: backup is coming from struct mptcp_subflow_request_sock, only one bit. Do the same here by using one bit for both. Fixes: efd340bf3d77 ("mptcp: distinguish rcv vs sent backup flag in request= s") Cc: stable@vger.kernel.org Reviewed-by: Geliang Tang Signed-off-by: Matthieu Baerts (NGI0) --- v2: update the Fixes tag (even if the target version is the same) --- net/mptcp/syncookies.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/net/mptcp/syncookies.c b/net/mptcp/syncookies.c index b5cac5701122..9474706641c1 100644 --- a/net/mptcp/syncookies.c +++ b/net/mptcp/syncookies.c @@ -26,7 +26,8 @@ struct join_entry { u32 local_nonce; u8 join_id; u8 local_id; - u8 backup; + u8 backup:1, + request_bkup:1; u8 valid; }; =20 @@ -63,6 +64,7 @@ static void mptcp_join_store_state(struct join_entry *ent= ry, entry->remote_nonce =3D subflow_req->remote_nonce; entry->local_nonce =3D subflow_req->local_nonce; entry->backup =3D subflow_req->backup; + entry->request_bkup =3D subflow_req->request_bkup; entry->join_id =3D subflow_req->remote_id; entry->local_id =3D subflow_req->local_id; entry->valid =3D 1; @@ -117,6 +119,7 @@ bool mptcp_token_join_cookie_init_state(struct mptcp_su= bflow_request_sock *subfl subflow_req->remote_nonce =3D e->remote_nonce; subflow_req->local_nonce =3D e->local_nonce; subflow_req->backup =3D e->backup; + subflow_req->request_bkup =3D e->request_bkup; subflow_req->remote_id =3D e->join_id; subflow_req->local_id =3D e->local_id; subflow_req->token =3D e->token; --=20 2.55.0 From nobody Fri Sep 25 20:48:29 2026 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 C0393241CB7; Tue, 8 Sep 2026 14:14:29 +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=1788876876; cv=none; b=NdeQzzVcHh6MOwzW+INy1WOBvYSBb2vQQl4ZQklfUIzAhTG5YVcLgIV6K2v/IrxPJd+t9zSDEQKcVfP50HikwGhWfmemeLI0WiOy8mwqQdxhH0+ncvbqlncM1arCyHajL3Fnjcne2zcZwGJXqF0Mn68ZlhaswGLQ5w5SCHM0W7g= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788876876; c=relaxed/simple; bh=xGnuahGwPP4f82k0zQU436ZpG60wJ/aEuwZt7vnyH40=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=JZMowbOyvbaJMgyEcJdSY8yHyvDzvm1srTkVqdecBgBvmfbMGSF/C06yaS+fPvjyrF1TRhMBk8gNz3KzY4oFGTpE2bXqoLTfs4nrPbFrJ9akpQxhocmTXx4yyjXnsIsoLgbYIHCQvSDu2CZnK5uVk/8usQCkUolRcTMEFe5WTPw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=HLmpwWLm; 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="HLmpwWLm" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8C2B81F00AC4; Tue, 8 Sep 2026 14:14:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1788876865; bh=NqkLnNdB1iaPRZgzHgODWa8SlkXcWwYoiM8hBJRiEzc=; h=From:Date:Subject:References:In-Reply-To:To:Cc; b=HLmpwWLmY3lKHL14XJaUCgEBnNq58yiKP83mpEFIqmWz6bCK4TKq2nH5sxqNhFb1Y RXF2lxMhMJZbEUGSzljRwYf6PZO9I17NCO+02uJyQuPszaZYUggDcldE1eUYrP5LEE cicSGXc7aKq/tiCZ3pY4KDt5Ub320fxgTxwfWYgcAS5aJynB7ws8a+W2nIfpCr/GSb e0CIObRQCMoT/HwyZ2XQz+ysKab2/w3h7Oz697/vfOZZUBlie1NqyH9GP4XPg3iile JcQqlibgQY2wMMoKKEEpkOCotM5vhFRaAZVRr93nvpDTHuripXqTM3EH3LRINpI3jE 2T1qzMKkPaxWw== From: "Matthieu Baerts (NGI0)" Date: Tue, 08 Sep 2026 16:07:09 +0200 Subject: [PATCH net v2 04/15] mptcp: pm: kernel: drop pending ADD_ADDR when removing ID0 Precedence: bulk X-Mailing-List: mptcp@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20260908-net-mptcp-misc-fixes-7-3-rc1-v2-4-df1de70348b6@kernel.org> References: <20260908-net-mptcp-misc-fixes-7-3-rc1-v2-0-df1de70348b6@kernel.org> In-Reply-To: <20260908-net-mptcp-misc-fixes-7-3-rc1-v2-0-df1de70348b6@kernel.org> To: Mat Martineau , Geliang Tang , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman Cc: netdev@vger.kernel.org, mptcp@lists.linux.dev, linux-kernel@vger.kernel.org, "Matthieu Baerts (NGI0)" , Kalpan Jani , stable@vger.kernel.org, syzbot+55c2a5c871441261ed14@syzkaller.appspotmail.com, Tao Cui X-Mailer: b4 0.16.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=2746; i=matttbe@kernel.org; h=from:subject:message-id; bh=BiUuBgq0c7aOBr6JJpkC2oZ8vE+NuO1ltFCd3RnPXgo=; b=owGbwMvMwCVWo/Th0Gd3rumMp9WSGLIWSGg+jpR9sNbqe1nXhsAXa379uDutLnXbovXn7/zav 0b1X/4OpY5SFgYxLgZZMUUW6bbI/JnPq3hLvPwsYOawMoEMYeDiFICJ/Ndn+Gd0e9v1v9Fh1xOO Vd13myd/YX9eZ2Xaaw/d9VUr1B41cisxMmzLNt0W/fz95528L7r9VhlP353YGSEjt/bf0ZqvZXr +/7gB X-Developer-Key: i=matttbe@kernel.org; a=openpgp; fpr=E8CB85F76877057A6E27F77AF6B7824F4269A073 From: Kalpan Jani The in-kernel MPTCP path manager can leave a stale ADD_ADDR announcement entry alive when removing the id 0 endpoint. This happens because the id 0 removal path does not tear down pending announcements, unlike the non-zero id path. When the PM later reselects id 0 after adding another signal endpoint, it finds the stale anno_list entry and hits WARN_ON_ONCE(mptcp_pm_is_kernel()) in mptcp_pm_announced_alloc(). Root cause: asymmetry between removal paths. - Non-zero id path: mptcp_nl_remove_subflow_and_signal_addr() calls mptcp_pm_remove_announced() to clean up. - Id 0 path: mptcp_nl_remove_id_zero_address() skips cleanup entirely. Fix by making the id 0 path symmetric: call mptcp_pm_announced_remove() and decrement add_addr_signaled before queuing the RM_ADDR. Subtle detail: signal endpoints are stored in anno_list with port 0, but msk_local carries the connection's local port. In other words, entries linked to ID0 paths should have port =3D=3D 0. A follow-up patch will ensure that. mptcp_pm_announced_remove() uses use_port=3Dtrue for comparison. So clear the port before the lookup. Fixes: 740d798e8767 ("mptcp: remove id 0 address") Cc: stable@vger.kernel.org Reported-by: syzbot+55c2a5c871441261ed14@syzkaller.appspotmail.com Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/620 Suggested-by: Tao Cui Signed-off-by: Kalpan Jani Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) --- v2: use new helpers name, note about "port =3D 0". --- net/mptcp/pm_kernel.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/net/mptcp/pm_kernel.c b/net/mptcp/pm_kernel.c index 424f1a7f9248..1a7750813235 100644 --- a/net/mptcp/pm_kernel.c +++ b/net/mptcp/pm_kernel.c @@ -1137,6 +1137,8 @@ static int mptcp_nl_remove_id_zero_address(struct net= *net, while ((msk =3D mptcp_token_iter_next(net, &s_slot, &s_num)) !=3D NULL) { struct sock *sk =3D (struct sock *)msk; struct mptcp_addr_info msk_local; + struct mptcp_addr_info anno_addr; + bool announced; =20 if (list_empty(&msk->conn_list) || mptcp_pm_is_userspace(msk)) goto next; @@ -1146,7 +1148,13 @@ static int mptcp_nl_remove_id_zero_address(struct ne= t *net, goto next; =20 lock_sock(sk); + /* Drop a possibly pending ADD_ADDR for this address. */ + anno_addr =3D msk_local; + anno_addr.port =3D 0; + announced =3D mptcp_pm_announced_remove(msk, &anno_addr); spin_lock_bh(&msk->pm.lock); + if (announced) + msk->pm.add_addr_signaled--; mptcp_pm_remove_addr(msk, &list); mptcp_pm_rm_subflow(msk, &list); __mark_subflow_endp_available(msk, 0); --=20 2.55.0 From nobody Fri Sep 25 20:48:29 2026 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 ABEBB2D2488; Tue, 8 Sep 2026 14:14:30 +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=1788876881; cv=none; b=CqQNzpfZrulEoDXemx8tS2VIgRLmr96He0X7iMr3YLKDUjiETVLzYMLp44jz89Q4x3HMlNdHSuLVnWmKXu9MsEb6p0U2baSZJ6feSQowJ/29a8jvWfNONr3S7b38VQafogp/ju/xP0sqnYdpvIvhI1GTZWJGmGmxmWXR/sf/bo0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788876881; c=relaxed/simple; bh=eCDaC8JU1hiplahjCkqNi+vidf1Fmw1XOI7fKun8pfo=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=Ef9kINlE9DR7v2KYy989VTj7F/by1A8ZoU/sILRe2jmRmna4sKSVPPIe5wBP25GxWQKgl8jkfnAbOzDqjR34p48lUrsqfAv2uc8Exn73aba2ALIr/2auN5kyPmQd/+1oXqPu7fTcPQJg2to03yN9Z1t2GNLkkYnc/SX4Z2R/nNw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ZUmTumhb; 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="ZUmTumhb" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5E8381F00ACA; Tue, 8 Sep 2026 14:14:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1788876867; bh=sb+mmGXsUplGkfw4gNxTxpAxsM0oDflslbitEXnYeqw=; h=From:Date:Subject:References:In-Reply-To:To:Cc; b=ZUmTumhbZtrJ+FlmeTIjijLFj9LJF1V+LYL0MqTzmSfgOLoMrBjFDxOlppeHcC1U8 HfXywVw/9d/RgoAct6yXlHa7rvN0iUFx3ceZ7Cd27GrXuowjOEmbNk8fvzPP2cT3Je IH/abw45B87JcAPgnwqp1uSRGvmz8X6c8pkH6r4bwBplz9yfGmOyNHru8p7b9ctEGB mIVvgJKdWO/nBz0zsJpfzz3FL1+1dP3E6gbZznIVoxn2g4vX8VIPRRMisAXbAP+j54 2yjWkk4ukTq9rkecIxOagx6eqEGW7stmbht/JLuhKmZ+piqUsnhkiNIqNiQEIHjoBQ 9XnVZr/1dsTQg== From: "Matthieu Baerts (NGI0)" Date: Tue, 08 Sep 2026 16:07:10 +0200 Subject: [PATCH net v2 05/15] mptcp: options: handle MPC data + csum reqd + no csum Precedence: bulk X-Mailing-List: mptcp@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20260908-net-mptcp-misc-fixes-7-3-rc1-v2-5-df1de70348b6@kernel.org> References: <20260908-net-mptcp-misc-fixes-7-3-rc1-v2-0-df1de70348b6@kernel.org> In-Reply-To: <20260908-net-mptcp-misc-fixes-7-3-rc1-v2-0-df1de70348b6@kernel.org> To: Mat Martineau , Geliang Tang , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman Cc: netdev@vger.kernel.org, mptcp@lists.linux.dev, linux-kernel@vger.kernel.org, "Matthieu Baerts (NGI0)" , stable@vger.kernel.org X-Mailer: b4 0.16.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=2883; i=matttbe@kernel.org; h=from:subject:message-id; bh=eCDaC8JU1hiplahjCkqNi+vidf1Fmw1XOI7fKun8pfo=; b=owGbwMvMwCVWo/Th0Gd3rumMp9WSGLIWSGjtPLW1RGdK/M3F0jduTDONZbxffvJo4IZ3O2dfv nI8ZlVMa0cpC4MYF4OsmCKLdFtk/sznVbwlXn4WMHNYmUCGMHBxCsBEltgw/OF6Znq7ufZu5CqT ZxMuFc3N8dNb/XfqAQ3Ns7XvZ88KWP2MkWHn9utH7h/6sXJBwp09Et+mLOzdL7H8x9r8+8Ga99x z3TW4AQ== X-Developer-Key: i=matttbe@kernel.org; a=openpgp; fpr=E8CB85F76877057A6E27F77AF6B7824F4269A073 Before this modification, a remote peer could send an MP_CAPABLE with data, with the checksum flag set, but without adding the actual 2 bytes of checksum. As a result, uninitialised bytes could be used for the 'csum' field. That was not a critical issue, because this 'csum' field is only used to compare with the expected one, if previously negotiated in the 3WHS. Worst case, the checksum is likely wrong, a fallback is done without a reject if the negotiation was done earlier. That's OK. Yet, better to take the expected path with this case: only look at the checksum flag for MP_CAPABLEs not carrying a data-len. Such packet can be seen as a 3rd or 4th ACK. The RFC8684 mentions [1] that the 3rd packet should have the checksum flag set. When an MPC + ACK contains data, the checksum flag is redundant with the checksum field. It is not clear what should be done for the 4th ACK, nor if the flag has to be set if the checksum field is set. Therefore, it seems fine to only look at the presence of the checksum field, not to break the interaction with stacks that were not setting both. Note that linked to this checksum flag on the 3rd ACK, with the current implementation, we can have a situation where the SYN packets have no checksum flag, but the 3rd ACK has one, and this is the one that will be taken into account. First, that's clearly not directly linked to this patch, but Clashiko forced us to look at that. At the end, that seems fine to act like that: yes that's not how the negotiation should work, but being flexible without introducing side effects is also fine: fixing this would mean increasing the complexity, and that's not worth it. Fixes: 208e8f66926c ("mptcp: receive checksum for MP_CAPABLE with data") Cc: stable@vger.kernel.org Link: https://datatracker.ietf.org/doc/html/rfc8684#section-3.1-23 [1] Closes: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260803-net-mp= tcp-misc-fixes-7-2-rc6-v2-0-b8f496d71664%40kernel.org?part=3D1 Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts (NGI0) --- Note about a non directly related case spotted by Clashiko. --- net/mptcp/options.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/net/mptcp/options.c b/net/mptcp/options.c index b8318e030138..92f27b9e087a 100644 --- a/net/mptcp/options.c +++ b/net/mptcp/options.c @@ -93,7 +93,8 @@ static void mptcp_parse_option(const struct sk_buff *skb, * In other words, the only way for checksums not to be used * is if both hosts in their SYNs set A=3D0." */ - if (flags & MPTCP_CAP_CHECKSUM_REQD) + if ((flags & MPTCP_CAP_CHECKSUM_REQD) && + opsize < TCPOLEN_MPTCP_MPC_ACK_DATA) mp_opt->suboptions |=3D OPTION_MPTCP_CSUMREQD; =20 mp_opt->deny_join_id0 =3D !!(flags & MPTCP_CAP_DENY_JOIN_ID0); --=20 2.55.0 From nobody Fri Sep 25 20:48:29 2026 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 80E865328AA; Tue, 8 Sep 2026 14:14:32 +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=1788876883; cv=none; b=TPSRv8puZAtlSSUHc4WOqLqsXg09eQPop+3Rs+jFLmDJrHANfozh4rqzZ5tg9lZQyxttglHbAmok8ryT4pJC46nq9Dl0NG95LhKEWz/elf4DgusaxFLPMy74Mz5VVocNbnQjsDwbC5t1v0lb7GNw7y2nVkcKkzj+aufO42uMS54= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788876883; c=relaxed/simple; bh=m5RufpM1iGzPPvtzkD1eeKoMvpDBVtPor9gzhjsGBTA=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=SxjDt2SXKTnkhPKG0whrerBZy0riHAeGlnF9sW0rQ99LxSZFV8hzikV76CfifKckRAIqSJKw/ZLmdpGGPWPi0OoImHyMSdZDqCDrihDtJV5GfwOf1EcjunHMjbC1yvWaVnpC4k3m+eWZcR2pf8+G4vUXIJlss6uJbLOOHKAPnOo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=a79RyTtH; 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="a79RyTtH" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B536F1F00ACF; Tue, 8 Sep 2026 14:14:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1788876869; bh=krhneQzf+Kzuapre9jYZgnLcjei4TLyTo9eSa6exwl8=; h=From:Date:Subject:References:In-Reply-To:To:Cc; b=a79RyTtHhqOg65iEaM9wJ5D1nDxKV8eCD/wRfqnHevWLFcvpo7cN6KbP0YSxOmUWy +a/7JvY4jwR26hlycJl5wbegCKKdg9Hu/9Iwfz7Q4roo+xlnglXBqm4GVHt6msurSe oAx5FyqeozkoD53HB2+x12Xy2imoVGFpuME7SZQlkbwqFtzMbl5rvIGp739/2IFKXI p+xvUS5Vu28bPWRxWnPhLnHy0LT7x6QhLdKgzWZckzWMD6QPANxwiK1GNSrKx/RQFI aK7vd7kTEM7uxX8HaM9p887xN6RPVivbeX8KwrgxzCowVGoPDRcQmDNEyB3o9zOz+g DXDjgqSSMNATw== From: "Matthieu Baerts (NGI0)" Date: Tue, 08 Sep 2026 16:07:11 +0200 Subject: [PATCH net v2 06/15] mptcp: prevent race between disconnect() and rtx Precedence: bulk X-Mailing-List: mptcp@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20260908-net-mptcp-misc-fixes-7-3-rc1-v2-6-df1de70348b6@kernel.org> References: <20260908-net-mptcp-misc-fixes-7-3-rc1-v2-0-df1de70348b6@kernel.org> In-Reply-To: <20260908-net-mptcp-misc-fixes-7-3-rc1-v2-0-df1de70348b6@kernel.org> To: Mat Martineau , Geliang Tang , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman Cc: netdev@vger.kernel.org, mptcp@lists.linux.dev, linux-kernel@vger.kernel.org, "Matthieu Baerts (NGI0)" X-Mailer: b4 0.16.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=1509; i=matttbe@kernel.org; h=from:subject:message-id; bh=o7fd5Gfi6MDOTSu1e2H4WVQGRPh7XaVrocJErKh//+8=; b=owGbwMvMwCVWo/Th0Gd3rumMp9WSGLIWSGjbrDUsdNGMOPiByfKg/Wx2rZUbNHOYD19fWVtc9 OP1bZe6jlIWBjEuBlkxRRbptsj8mc+reEu8/Cxg5rAygQxh4OIUgIn8vMbw36l/oYFJ85ETG799 f9m9lcP0/IMU86d/X3AkznJi8Fj5nZfhn17R0euuFye4s2vL7TkQ2HlazPNIkOHn/xscs3fHt9n kMQEA X-Developer-Key: i=matttbe@kernel.org; a=openpgp; fpr=E8CB85F76877057A6E27F77AF6B7824F4269A073 From: Paolo Abeni Sashiko noted that the two event can race, leading to inconsistent status. Prevent the race using the synchronous timer stop operation. Fixes: b29fcfb54cd7 ("mptcp: full disconnect implementation") Signed-off-by: Paolo Abeni Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) --- net/mptcp/protocol.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c index be59651e708e..d611af2eb74f 100644 --- a/net/mptcp/protocol.c +++ b/net/mptcp/protocol.c @@ -3588,6 +3588,7 @@ static void mptcp_destroy_common(struct mptcp_sock *m= sk) =20 static int mptcp_disconnect(struct sock *sk, int flags) { + struct inet_connection_sock *icsk =3D inet_csk(sk); struct mptcp_sock *msk =3D mptcp_sk(sk); =20 /* We are on the fastopen error path. We can't call straight into the @@ -3600,8 +3601,13 @@ static int mptcp_disconnect(struct sock *sk, int fla= gs) mptcp_check_listen_stop(sk); mptcp_set_state(sk, TCP_CLOSE); =20 - mptcp_stop_rtx_timer(sk); - mptcp_stop_tout_timer(sk); + /* The later subflow close can not kick again the tout timer, + * as the msk is already in closed status. + */ + msk->timer_ival =3D icsk->icsk_rto_min; + sk_stop_timer_sync(sk, &sk->mptcp_retransmit_timer); + icsk->icsk_mtup.probe_timestamp =3D 0; + sk_stop_timer_sync(sk, &icsk->mptcp_tout_timer); =20 mptcp_pm_connection_closed(msk); =20 --=20 2.55.0 From nobody Fri Sep 25 20:48:29 2026 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 87E765540A9; Tue, 8 Sep 2026 14:14:32 +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=1788876882; cv=none; b=RjDiW0k7LuOwl36Uz0akZeUEkfvJmBbSJDL11lBHauWGNB38u47yXD9A2bZA+3xSRxe11nP5VaYHRc6X3eTQ/MCBgDcWJGT5lPf6HggcacPF3IbHVJZ8kR+39CGAahh3UdjhOwK1GLxVMwBPy2wXdF9b2/QbENZvZrDgREWU38U= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788876882; c=relaxed/simple; bh=8JjDG2J3jEdCZkbqt3U//6l4ggwme3t78z+VOG5XkDk=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=InMbnZPTqBrTZXMYHGycwhzHkU1tKlLXAC/xFaGLjCPb0JWzwhf08D0wL6UaZu4Yu8eaMWXm9SIguk+XLue+UtjpJw/dWflPPY+I7GfJs6VuseHWjQPh5HjGsCoGhdT+22UzJ5OcaHNoUc4AAtvhsCTB05hnxKl0PNxJsry+vdA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=hLQWE+6t; 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="hLQWE+6t" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E7C9A1F00A3D; Tue, 8 Sep 2026 14:14:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1788876872; bh=bI1QFqme7+lJ2wpHo1+LquJZx4pXgkY27jmIYw7Nq6E=; h=From:Date:Subject:References:In-Reply-To:To:Cc; b=hLQWE+6tYqw8dRYth7l9ETFNf4PHqPHGwio52LkyvJp4WA1DvPuVl66scUUbcAuW3 htYbBUVVFYRQcGJjXwkcgbErzmNMAGFLBqgdtex9tzEW6/88eVKni4JF8nk0ClIY0q UKUNaXg+baVlvj8wKYrFsNfI2kkDoItHwe3cl6n3VeUv3ONglLXux/ASJSUCC3b7Uw yDYMpDyV3JbeO8BJpIJt6Ur5TUUN6B2BHHxMzF+nAbqgqTY+UWzOn0YCXfneJEQzMy ZzWlL/uTIdbmHjqwRTYf1Vgd6lvdrqyxlG8AiOIN44D3lpSQViOICNHT9kIhaM9YnK BGxAaxBA9d+0g== From: "Matthieu Baerts (NGI0)" Date: Tue, 08 Sep 2026 16:07:12 +0200 Subject: [PATCH net v2 07/15] selftests: mptcp: fix an UAF in mptcp_connect.c Precedence: bulk X-Mailing-List: mptcp@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20260908-net-mptcp-misc-fixes-7-3-rc1-v2-7-df1de70348b6@kernel.org> References: <20260908-net-mptcp-misc-fixes-7-3-rc1-v2-0-df1de70348b6@kernel.org> In-Reply-To: <20260908-net-mptcp-misc-fixes-7-3-rc1-v2-0-df1de70348b6@kernel.org> To: Mat Martineau , Geliang Tang , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman Cc: netdev@vger.kernel.org, mptcp@lists.linux.dev, linux-kernel@vger.kernel.org, "Matthieu Baerts (NGI0)" , Gang Yan , stable@vger.kernel.org, Shuah Khan , linux-kselftest@vger.kernel.org X-Mailer: b4 0.16.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=1876; i=matttbe@kernel.org; h=from:subject:message-id; bh=z1iJ73EI6mQ/ELE58y3y+0cCYyNXtjGYVHzqia9Z/wc=; b=owGbwMvMwCVWo/Th0Gd3rumMp9WSGLIWSOikTO9ZY3HypsMioRjWrQ0SkvIss+8cDVz7+3ziZ XP3BW+MO0pZGMS4GGTFFFmk2yLzZz6v4i3x8rOAmcPKBDKEgYtTACYy5wYjw7QvD3b+NjqtVtTl /W9+XVN8YN2H4JltDNXfql1Vo/L29TMyzE8tOZx2Tv3FSafMrNiXAcrbOFlmXJr4PuFXT6rwIYN MDgA= X-Developer-Key: i=matttbe@kernel.org; a=openpgp; fpr=E8CB85F76877057A6E27F77AF6B7824F4269A073 From: Gang Yan At the end of 'sock_connect_mptcp()', it calls 'freeaddrinfo(addr)', the 'peer' pointer (which points into 'addr') remains. Later, the main loop uses this peer pointer for reconnection attempts. If the memory has been freed and reused, the address data could be overwritten, resulting in an invalid remote address. This patch keeps the addrinfo list allocated for the whole process lifetime so "peer" remains valid across reconnects; the memory will be released at exit() time. Fixes: 05be5e273c84 ("selftests: mptcp: add disconnect tests") Cc: stable@vger.kernel.org Suggested-by: Paolo Abeni Signed-off-by: Gang Yan Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) --- Cc: Shuah Khan Cc: linux-kselftest@vger.kernel.org --- tools/testing/selftests/net/mptcp/mptcp_connect.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/tools/testing/selftests/net/mptcp/mptcp_connect.c b/tools/test= ing/selftests/net/mptcp/mptcp_connect.c index ea4cb6c1bd5e..178d98d91fea 100644 --- a/tools/testing/selftests/net/mptcp/mptcp_connect.c +++ b/tools/testing/selftests/net/mptcp/mptcp_connect.c @@ -381,6 +381,9 @@ static int sock_connect_mptcp(const char * const remote= addr, =20 hints.ai_family =3D pf; =20 + /* Keep the resolved address alive for the whole execution: it is + * used again when reconnecting, and will be released at exit time. + */ xgetaddrinfo(remoteaddr, port, &hints, &addr); for (a =3D addr; a; a =3D a->ai_next) { sock =3D socket(a->ai_family, a->ai_socktype, proto); @@ -421,7 +424,6 @@ static int sock_connect_mptcp(const char * const remote= addr, sock =3D -1; } =20 - freeaddrinfo(addr); if (sock !=3D -1) SOCK_TEST_TCPULP(sock, proto); return sock; --=20 2.55.0 From nobody Fri Sep 25 20:48:29 2026 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 66FC15328D3; Tue, 8 Sep 2026 14:14:38 +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=1788876891; cv=none; b=BBr9fgrdfwZCFIVSZ9TZ9pKqlhBdLpD3oYvjXU2fiOrNhjtO0gFrEO7HjSin6vvZzZ7BjW0lsDwrv760z8tFf64Hv/diKBk5F9tMPL50UQWeKk4AoWqwrq0klDro10EyRlfDedbuXIGHt7Rh7cbyvPOLxREawvebMeInDKqchsY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788876891; c=relaxed/simple; bh=ffiRbKuLcxin3A/WteZmozAqUov6MY2AXBJ4V8VM/uo=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=pG9H3GDXJhRUASnppJr+2Z43S6ddE4P/GRaONjc65Jo1+TFkYNxuWTbtqAl2wiUyo6UzWNYUaFAb4HEr4vlZjy7mDTc4dR1s5cWzn44Dk9zohMQkqi1Zl+xH/8khO9PJNGXdXZoIU+ufVodCHzPjuVl3E7TgN20SKa8BimuCvPY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=g5bMq9YE; 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="g5bMq9YE" Received: by smtp.kernel.org (Postfix) with ESMTPSA id BAA571F00A3A; Tue, 8 Sep 2026 14:14:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1788876875; bh=e6nwdDW9Dbh9wjzItEeoZ2mpyN9We/YnsvBrCCz/FUI=; h=From:Date:Subject:References:In-Reply-To:To:Cc; b=g5bMq9YErnC+gbI4dHdjAY0HtZ0nA94Nd4Jt7H3pge0mwNFCTXUj0mda5xpmfmKVS MQ/wrgkA/N7mBwECwMDwLCIXlSGGJaGFDQ+5ixABR1lfbTNPJMo2SEI+ahEvfp+SCT ETjw5aZ1ji4Z1m8ZzajGKTRLkawWtyql2GbRwbdbg9G8ZNb01U9sVbcCRKpKdrDdhD 5beoP81TfgCeRjBR5sVGIYkka3RCYbYqAlwXLTa6fi+Y3Pwz+HPWmHhMkout8UYKCr U8VQNtWR8YWEQG1S3dt6yo7VoBYuEbmHw/VnakoOGyFHiJz3A5kAAu7lMUEKua/U6W I2+6FTUmh6/zg== From: "Matthieu Baerts (NGI0)" Date: Tue, 08 Sep 2026 16:07:13 +0200 Subject: [PATCH net v2 08/15] mptcp: pm: userspace: fix address ID overflow Precedence: bulk X-Mailing-List: mptcp@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20260908-net-mptcp-misc-fixes-7-3-rc1-v2-8-df1de70348b6@kernel.org> References: <20260908-net-mptcp-misc-fixes-7-3-rc1-v2-0-df1de70348b6@kernel.org> In-Reply-To: <20260908-net-mptcp-misc-fixes-7-3-rc1-v2-0-df1de70348b6@kernel.org> To: Mat Martineau , Geliang Tang , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman Cc: netdev@vger.kernel.org, mptcp@lists.linux.dev, linux-kernel@vger.kernel.org, "Matthieu Baerts (NGI0)" , Qing Luo , stable@vger.kernel.org, Kishen Maloor X-Mailer: b4 0.16.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=2431; i=matttbe@kernel.org; h=from:subject:message-id; bh=hEpKFWxV5Gco76wOpHpHe3xccke8Fe8uRlOsRHjFtXI=; b=owGbwMvMwCVWo/Th0Gd3rumMp9WSGLIWSOiy8nzmOJDi5azRvvbBT97asLby4C+iF45ONmMw+ d7feu9MRykLgxgXg6yYIot0W2T+zOdVvCVefhYwc1iZQIYwcHEKwERYJBj+6QS/0VX7r592zrPZ au6rtXorHcsOiTxyvLnkth3bryA5GUaGL7/cXlmGv58w+7XA3Ko4ZT2lRxcvpTF4n6t7PbVzx6E lPAA= X-Developer-Key: i=matttbe@kernel.org; a=openpgp; fpr=E8CB85F76877057A6E27F77AF6B7824F4269A073 From: Qing Luo When all MPTCP address IDs (1-255) are exhausted in the userspace PM, find_next_zero_bit() returns MPTCP_PM_MAX_ADDR_ID + 1 (256). This value overflows when stored in the u8 field e->addr.id, resulting in ID 0 being stored and the entry being incorrectly added to the list. ID 0 is reserved for the initial connection in MPTCP, so this overflow can cause address conflicts. Note: the in-kernel PM already has an 'endpoints =3D=3D MPTCP_PM_MAX_ADDR_I= D' check in mptcp_pm_nl_append_new_local_addr() that returns -ERANGE before reaching find_next_zero_bit(), preventing this overflow. So this fix only addresses the userspace PM path. Check the find_next_zero_bit() result against MPTCP_PM_MAX_ADDR_ID and return -ENOSPC if all IDs are truly exhausted. Move the ID allocation check before the memory allocation so that the error path does not need to free the allocated entry. Fixes: 4638de5aefe5 ("mptcp: handle local addrs announced by userspace PMs") Cc: stable@vger.kernel.org Assisted-by: LLM:0 Signed-off-by: Qing Luo Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) --- Cc: Kishen Maloor --- net/mptcp/pm_userspace.c | 18 ++++++++++++++---- 1 file changed, 14 insertions(+), 4 deletions(-) diff --git a/net/mptcp/pm_userspace.c b/net/mptcp/pm_userspace.c index b94fbb483bf9..fab16d953dbf 100644 --- a/net/mptcp/pm_userspace.c +++ b/net/mptcp/pm_userspace.c @@ -69,6 +69,19 @@ static int mptcp_userspace_pm_append_new_local_addr(stru= ct mptcp_sock *msk, } =20 if (!addr_match && !id_match) { + unsigned int id; + + if (!entry->addr.id && needs_id) { + id =3D find_next_zero_bit(id_bitmap, + MPTCP_PM_MAX_ADDR_ID + 1, 1); + if (id > MPTCP_PM_MAX_ADDR_ID) { + ret =3D -ENOSPC; + goto append_err; + } + } else { + id =3D entry->addr.id; + } + /* Memory for the entry is allocated from the * sock option buffer. */ @@ -78,10 +91,7 @@ static int mptcp_userspace_pm_append_new_local_addr(stru= ct mptcp_sock *msk, goto append_err; } =20 - if (!e->addr.id && needs_id) - e->addr.id =3D find_next_zero_bit(id_bitmap, - MPTCP_PM_MAX_ADDR_ID + 1, - 1); + e->addr.id =3D id; list_add_tail_rcu(&e->list, &msk->pm.userspace_pm_local_addr_list); msk->pm.local_addr_used++; ret =3D e->addr.id; --=20 2.55.0 From nobody Fri Sep 25 20:48:29 2026 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 D4C2A4B2CD7; Tue, 8 Sep 2026 14:14:40 +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=1788876892; cv=none; b=OTvFrwIv2OCX3DSSBH157v0OkOWTcWc+raAM8BzIx3XNRrmFLkGP9ILptEc5HHlUT1Dne7/YDqXGrIE/ulYfvwBJmnKv3PErOO088C8SGJxw69Xgl9QEJkpiyJLvO5D8KnWKlNNrh3vtvSTjRgJ3AalXRX71q8wSMnXbb5P8I3g= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788876892; c=relaxed/simple; bh=rDbSGSAmVFbg0E1fLJuj2J9IXWeWyHNTwxjz99I+YJg=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=gHrgVF0Bax6M7y7cIfgquNZX6vsfI77nj+x4D06X7bgzbSIXFtfipE7i+S3EfBc1d8FknpnbJbXvKLzXL6STrzzYlbB9n6hjVANgTMPDI96veFsA3Vokn3fHsUenei6cdtzP+XioFgqNsEGaLX7WRigYsyPPuv38O+oEc5GQySk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=MU0ApHEW; 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="MU0ApHEW" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 67B921F00A3E; Tue, 8 Sep 2026 14:14:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1788876877; bh=zr04WX9th+houH+FrgG3Exh8ghBTSa1pugxeGkEkLuQ=; h=From:Date:Subject:References:In-Reply-To:To:Cc; b=MU0ApHEWWaK64ETlIc2Aw3tiSFKFaoJt16hfHpBZuCyDGV7dgXJFOprXtYFynTb8M TDC6sOyN6E9zItE5n9a0/MywJJHNaaEa4KUWFpb8A3A34Df8/gytelGmmob+xyjxT3 Rf6Tll7DSJn3y1Mc5uBRT9+15eJPbxUm2HiWFxtvLLOI+JfCZWLcuSOUDnITytZAAC is6EAmeY24mywRhrQp/CZ7Qdl2T+78wSzz1nAWYshv6oKKTqZ/21t1Hup6uji7r2Ah fyqTQrgzh704aowWaYViVGNv2oDbR44DWKkLY8+3IThyfdyOh69ak1ztmSyRmT8LQi fTmH+flhdFv2w== From: "Matthieu Baerts (NGI0)" Date: Tue, 08 Sep 2026 16:07:14 +0200 Subject: [PATCH net v2 09/15] mptcp: pm: reset retrans_time when ADD_ADDR entry is reused Precedence: bulk X-Mailing-List: mptcp@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20260908-net-mptcp-misc-fixes-7-3-rc1-v2-9-df1de70348b6@kernel.org> References: <20260908-net-mptcp-misc-fixes-7-3-rc1-v2-0-df1de70348b6@kernel.org> In-Reply-To: <20260908-net-mptcp-misc-fixes-7-3-rc1-v2-0-df1de70348b6@kernel.org> To: Mat Martineau , Geliang Tang , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman Cc: netdev@vger.kernel.org, mptcp@lists.linux.dev, linux-kernel@vger.kernel.org, "Matthieu Baerts (NGI0)" , stable@vger.kernel.org, Kishen Maloor X-Mailer: b4 0.16.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=1373; i=matttbe@kernel.org; h=from:subject:message-id; bh=rDbSGSAmVFbg0E1fLJuj2J9IXWeWyHNTwxjz99I+YJg=; b=owGbwMvMwCVWo/Th0Gd3rumMp9WSGLIWSOgKerSa9qp1LGBZ33pZMchO61vyKoYdgmrvCpS3L Ff1X8rSUcrCIMbFICumyCLdFpk/83kVb4mXnwXMHFYmkCEMXJwCMBG25YwM17ff3tvZIvf+lznD wYJFLKsvXXs+13JfweVHxyOvT1rzlonhf7GywLH3OXPqfDzOLBZi8FNJqApNvVkg1GT4yGx+cdc GZgA= X-Developer-Key: i=matttbe@kernel.org; a=openpgp; fpr=E8CB85F76877057A6E27F77AF6B7824F4269A073 When an ADD_ADDR entry is reused, the timer is re-armed, because the goal is to re-announce an ADD_ADDR, and eventually retransmit it if needed. In this case, the retransmission counter should be reset as well, so the re-announced address gets its retransmissions back instead of relying on what was left before, and possibly not being able to retransmit it. Fixes: 304ab97f4c7c ("mptcp: allow ADD_ADDR reissuance by userspace PMs") Cc: stable@vger.kernel.org Link: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260803-net-mptc= p-misc-fixes-7-2-rc6-v2-0-b8f496d71664%40kernel.org?part=3D4 Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts (NGI0) --- Cc: Kishen Maloor --- net/mptcp/pm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/mptcp/pm.c b/net/mptcp/pm.c index 8b68868255c5..b0b71adefb8f 100644 --- a/net/mptcp/pm.c +++ b/net/mptcp/pm.c @@ -462,10 +462,10 @@ bool mptcp_pm_announced_alloc(struct mptcp_sock *msk, =20 add_entry->addr =3D *addr; add_entry->sock =3D msk; - add_entry->retrans_times =3D 0; =20 timer_setup(&add_entry->timer, mptcp_pm_add_addr_timer, 0); reset_timer: + add_entry->retrans_times =3D 0; add_entry->timer_done =3D false; timeout =3D mptcp_adjust_add_addr_timeout(msk); if (timeout) --=20 2.55.0 From nobody Fri Sep 25 20:48:29 2026 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 464E5559CB6; Tue, 8 Sep 2026 14:14:41 +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=1788876887; cv=none; b=QqJ2JN5ec2azpBm1/AcUzO9bCzhKEIObyY8vog52I3+DtYYP8JKKaeXFzJQuJxjKHkOMJWK8dmPx0z/KLpZynnaIaFK3UOVqVyCV4COl9G/F7gVp6UocoFmxgBMebY8aVVFIvizNCxVST2zFXycTuTY5jShGLLUbIHnIZguxT/g= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788876887; c=relaxed/simple; bh=oGg5rpzKcZ0L7xt8P9FjM5bph6IJRj54n6TDVtLgUkU=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=ZojM9W7XpMxWnrlfHz77N1uLVnMs2xOrm1QzlgfqN/UhNeK3CPmhQvmd67Tb1t6YymLNrMEa5mMe4abL/Xsn/+xkCcyHInYjMKGD2o9jwRtGWo1bxaR9FKkQnk7gPSLyeKC2D/aTLN/vRTLPRY+k4fnQ97SCl3Vdu5+n2keLJGk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=QR32VUuP; 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="QR32VUuP" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E34931F00A3F; Tue, 8 Sep 2026 14:14:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1788876879; bh=qtOzBM71tbq3AelkzbXg+5WrvGROzIDwE+oJeoYFn5k=; h=From:Date:Subject:References:In-Reply-To:To:Cc; b=QR32VUuPlx5DNPKwzbqMyg7jMhKh+42zwwn2Snm867aGiCaB2BHUCKCIR0FNIzLRu oC3hjohdhy3RKKpyRABO5Z0nyd4Hw8vgNtcSDwemxxPTVoTuuYV5eA0eX5EBDstfm5 EmkoKwQe/xqOr1iK6KIBRx/uK8uTNSOhJDUF/l4ihANprJFukhdN/BB+EyViAFIVBu II1KTzX2TOi727lJf+HNGds1rAYo+zyQ7Sw8D2tBVFfpJYgjSfDYSwQ3AS9Rxq8mps 3uM5rE4bDgO3ESwbgMzSJoGUiixm9tWevbSCxExkc5ZaEEfacUgnPCbddhDy3wwWbN qmPocVea7NePg== From: "Matthieu Baerts (NGI0)" Date: Tue, 08 Sep 2026 16:07:15 +0200 Subject: [PATCH net v2 10/15] mptcp: remove unneeded READ_ONCE() annotation Precedence: bulk X-Mailing-List: mptcp@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20260908-net-mptcp-misc-fixes-7-3-rc1-v2-10-df1de70348b6@kernel.org> References: <20260908-net-mptcp-misc-fixes-7-3-rc1-v2-0-df1de70348b6@kernel.org> In-Reply-To: <20260908-net-mptcp-misc-fixes-7-3-rc1-v2-0-df1de70348b6@kernel.org> To: Mat Martineau , Geliang Tang , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman Cc: netdev@vger.kernel.org, mptcp@lists.linux.dev, linux-kernel@vger.kernel.org, "Matthieu Baerts (NGI0)" , Gang Yan X-Mailer: b4 0.16.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=2206; i=matttbe@kernel.org; h=from:subject:message-id; bh=9eqb5VAzLubwvmVesR3TSDdXsSEDUwLnEuSftEbmfNY=; b=owGbwMvMwCVWo/Th0Gd3rumMp9WSGLIWSOgZmApNWy488W/vhy4OpR9PPrZlrX3K4zvJrnv1t rutGky2HaUsDGJcDLJiiizSbZH5M59X8ZZ4+VnAzGFlAhnCwMUpABMRnsHIcIahMyGtVO2Ra4Rb 2RNp3hnbHbYufiFU/tNr7ZSIDU9DZjL8L1iqbGCd8fL8zcyptZyTHAPvTY3a8Sel/d26bRyf8zi 3cwMA X-Developer-Key: i=matttbe@kernel.org; a=openpgp; fpr=E8CB85F76877057A6E27F77AF6B7824F4269A073 From: Paolo Abeni The subflow->fully_established flag is always written under the subflow socket lock. Reading such value under the same lock does not require any ONCE annotation. Fixes: 581c8cbfa934 ("mptcp: annotate data-races around subflow->fully_esta= blished") Signed-off-by: Paolo Abeni Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) --- Cc: Gang Yan v2: no need to cc stable. --- net/mptcp/options.c | 4 ++-- net/mptcp/protocol.c | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/net/mptcp/options.c b/net/mptcp/options.c index 92f27b9e087a..196a46e7467d 100644 --- a/net/mptcp/options.c +++ b/net/mptcp/options.c @@ -530,7 +530,7 @@ static bool mptcp_established_options_mp(struct sock *s= k, struct sk_buff *skb, return false; =20 /* MPC/MPJ needed only on 3rd ack packet, DATA_FIN and TCP shutdown take = precedence */ - if (READ_ONCE(subflow->fully_established) || snd_data_fin_enable || + if (subflow->fully_established || snd_data_fin_enable || subflow->snd_isn !=3D TCP_SKB_CB(skb)->seq || sk->sk_state !=3D TCP_ESTABLISHED) return false; @@ -981,7 +981,7 @@ static bool check_fully_established(struct mptcp_sock *= msk, struct sock *ssk, /* here we can process OoO, in-window pkts, only in-sequence 4th ack * will make the subflow fully established */ - if (likely(READ_ONCE(subflow->fully_established))) { + if (likely(subflow->fully_established)) { /* on passive sockets, check for 3rd ack retransmission * note that msk is always set by subflow_syn_recv_sock() * for mp_join subflows diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c index d611af2eb74f..302936ff456a 100644 --- a/net/mptcp/protocol.c +++ b/net/mptcp/protocol.c @@ -3886,7 +3886,7 @@ static void schedule_3rdack_retransmission(struct soc= k *ssk) struct tcp_sock *tp =3D tcp_sk(ssk); unsigned long timeout; =20 - if (READ_ONCE(mptcp_subflow_ctx(ssk)->fully_established)) + if (mptcp_subflow_ctx(ssk)->fully_established) return; =20 /* reschedule with a timeout above RTT, as we must look only for drop */ --=20 2.55.0 From nobody Fri Sep 25 20:48:29 2026 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 4635C513552; Tue, 8 Sep 2026 14:14:42 +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=1788876899; cv=none; b=WWbMagBfSQSP6g/C2yRjxJQgL6bxoqj5J28AwkHiGMSVoX660T69MEcfUaDCr9tgfcHnD7F6CZr/wFo0RbA3iGmy2uIE+kOhsyf3c9Gl9xoJHLXYuk3oR5emh4F6qWTBRaLuU83paaI0LZ/U+ZyAmzyhcOPzR37in9qasY6Aw6Y= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788876899; c=relaxed/simple; bh=c5IXRGjuz0fSPa4V5Xz2gLhzLB899t5Sk/STYYx7jXw=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=NCwMmkQvUcqUt6+IJHpK2/781tKhYbIghMMUwkHKJhudQCTT84HdwG9oD4zXdP/NaWv4IAPmCYRNusc14FbJVObItfGpxs5qrk7LuEoqOZm/PrSgulqyjDHerYyn2r9+3g2NUA691V7K587N84QEIPVfsb0cQxGgfloE7qEX0yc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Zlb8d3lD; 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="Zlb8d3lD" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 454511F00AC4; Tue, 8 Sep 2026 14:14:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1788876882; bh=oCwaDeVCnMEOM3Suj5i1JtmGB4sF4AjuaGS8MXJAUMg=; h=From:Date:Subject:References:In-Reply-To:To:Cc; b=Zlb8d3lDTI3j816xJQJWU2xsXUNOVRup5KU1RLEIL58RlxNK+7SyN4rJznxthjVG/ /hO69OTWrjMJz6H+GNRRhipxbdkuaV46BDgDAGvGrUV5xujkUn1mfX+ghYNZTN5SIr sqWDDpph/e3ajmp3/5Ab4yL321L97YWJ64fwDLYzYgwXNEHlE61RRNzSlVgFE+ug3G nRcabVn2QNEduwG/6dirafSmylmoXuyCRVljrPTnq/z+t9CDqsFULCbTzyV1k0x8LJ NJu0x8kxXjOFIFKkzD161xXQePYvtoxTTBpar9nXtVOtkmgoKmiRMfvOmxEYGlzHZ/ 4p8JhfP6j/PaA== From: "Matthieu Baerts (NGI0)" Date: Tue, 08 Sep 2026 16:07:16 +0200 Subject: [PATCH net v2 11/15] selftests: mptcp: lib: dump nstat for the right test Precedence: bulk X-Mailing-List: mptcp@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20260908-net-mptcp-misc-fixes-7-3-rc1-v2-11-df1de70348b6@kernel.org> References: <20260908-net-mptcp-misc-fixes-7-3-rc1-v2-0-df1de70348b6@kernel.org> In-Reply-To: <20260908-net-mptcp-misc-fixes-7-3-rc1-v2-0-df1de70348b6@kernel.org> To: Mat Martineau , Geliang Tang , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman Cc: netdev@vger.kernel.org, mptcp@lists.linux.dev, linux-kernel@vger.kernel.org, "Matthieu Baerts (NGI0)" , stable@vger.kernel.org, Shuah Khan , linux-kselftest@vger.kernel.org X-Mailer: b4 0.16.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=1903; i=matttbe@kernel.org; h=from:subject:message-id; bh=c5IXRGjuz0fSPa4V5Xz2gLhzLB899t5Sk/STYYx7jXw=; b=owGbwMvMwCVWo/Th0Gd3rumMp9WSGLIWSOgryodM9s04z7lPMDnAMvvlpKrsSPPjocFmi60MZ Rjap6ztKGVhEONikBVTZJFui8yf+byKt8TLzwJmDisTyBAGLk4BmEhCIMN/Lxk1dYnHonoR/3hM /t1ee96rfUHMBK9Dbn7b/PYwXjbaw/BX0qX4zP8GGUfN1RpFJrpcHK/1/61kOXRP4d67BxZcB9M 4AQ== X-Developer-Key: i=matttbe@kernel.org; a=openpgp; fpr=E8CB85F76877057A6E27F77AF6B7824F4269A073 In case of errors, mptcp_lib_pr_nstat is called to dump the nstat counters, but for some tests, it was dumping the counters for all subtests, not just the current one. That's an issue for tests that don't recreate the netns for each subtest, e.g. mptcp_connect.sh. In this case, 'nstat -a' will look at the absolute counters since the creation of the netns, making debugging harder. Instead, it should dump the counters for the current test, by using the history recorded in /tmp/.nstat if available, and not using '-a' which was dumping the absolute values instead of calculating increments. While at it, rename the previous 'hist' variable to 'cache' as it was used to look at the cache, not the nstat history. Fixes: 658e53141780 ("selftests: mptcp: join: dump stats from history") Cc: stable@vger.kernel.org Reviewed-by: Geliang Tang Signed-off-by: Matthieu Baerts (NGI0) --- Cc: Shuah Khan Cc: linux-kselftest@vger.kernel.org --- tools/testing/selftests/net/mptcp/mptcp_lib.sh | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/tools/testing/selftests/net/mptcp/mptcp_lib.sh b/tools/testing= /selftests/net/mptcp/mptcp_lib.sh index 5ef6033775c8..da1da414c30f 100644 --- a/tools/testing/selftests/net/mptcp/mptcp_lib.sh +++ b/tools/testing/selftests/net/mptcp/mptcp_lib.sh @@ -108,12 +108,14 @@ mptcp_lib_pr_info() { =20 mptcp_lib_pr_nstat() { local ns=3D"${1}" - local hist=3D"/tmp/${ns}.out" + local cache=3D"/tmp/${ns}.out" + local hist=3D"/tmp/${ns}.nstat" =20 - if [ -f "${hist}" ]; then - awk '$2 !=3D 0 { print " "$0 }' "${hist}" + if [ -f "${cache}" ]; then + awk '$2 !=3D 0 { print " "$0 }' "${cache}" else - ip netns exec "${ns}" nstat -as | grep Tcp + NSTAT_HISTORY=3D"${hist}" ip netns exec "${ns}" nstat -s | + grep Tcp fi } =20 --=20 2.55.0 From nobody Fri Sep 25 20:48:29 2026 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 3698C552920; Tue, 8 Sep 2026 14:14:46 +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=1788876897; cv=none; b=IeVRKYmab1us0tQD/b1i6cjSBQWgTUpjhAKF9GA161gUd2WMIg+BweS6WKJVFw3anfj2mYVa4ScqDgquJnoYTZgRI5SMELmfLxLmh2o1HucVd2ri0DQSEoBEzs+kAMbRVWjRkxP+IaM5hJDM0T1Vx5EqObpxAf9xBAZYmFwm8t8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788876897; c=relaxed/simple; bh=CCaezY8L2QGxE1d8YVG+RIwjuxy2v9Yrtn18wTD4RmU=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=qETOOV5akPjrL96Xp/L1zRVbgHNk3yjLfXjqhPpRuE96OZyXELHOTCZphLeA1lqftyRHrls94Rv3mRg6ebcw6S3KDs2yOYlbnWtuj3/GHX1qB5k1V779Ozmtcj1QpwyP1CN+dMKS2+UPzy/PDe3OMdv97gF/QlXSLiZoDfKFxHE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Io/D9wmq; 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="Io/D9wmq" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E71441F00A3D; Tue, 8 Sep 2026 14:14:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1788876885; bh=nt14iCy2+3ATRgf1ASvH3cbgbaTCA1uqYuD/SL6AALg=; h=From:Date:Subject:References:In-Reply-To:To:Cc; b=Io/D9wmqvKDw1HZ1UlOpw5WRs7Sh6y9emFzUX4mzxqWAySra1rXI6rB1/4DC1rqAH 6Znug0rgJRb1OPQEYwVey3PQOX2Y4ocrVd97Bkd/hjh67Jzprn49EIrZlTrOX2CRMZ SyhrM5sek0LbHmdLUNAwmcxpfkhBwQCmBkPUThQj/J+4e6sIwPP3p3/OfRvuLWZFIa 0jXqRqD8LQbxBJYR1GWUAa6T+7Bq8dSf5qPiEgtPmRWuitqiSyW6yy8cfYIodpdk1X u6jpv9ft2MkM2s0bFomst1VwMxpA6mZdhNqpqTQf6BNGB0K5uckYGjKzRh40uvE8GU nqanft1mRZ4/g== From: "Matthieu Baerts (NGI0)" Date: Tue, 08 Sep 2026 16:07:17 +0200 Subject: [PATCH net v2 12/15] selftests: mptcp: lib: get counters for the right test Precedence: bulk X-Mailing-List: mptcp@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20260908-net-mptcp-misc-fixes-7-3-rc1-v2-12-df1de70348b6@kernel.org> References: <20260908-net-mptcp-misc-fixes-7-3-rc1-v2-0-df1de70348b6@kernel.org> In-Reply-To: <20260908-net-mptcp-misc-fixes-7-3-rc1-v2-0-df1de70348b6@kernel.org> To: Mat Martineau , Geliang Tang , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman Cc: netdev@vger.kernel.org, mptcp@lists.linux.dev, linux-kernel@vger.kernel.org, "Matthieu Baerts (NGI0)" , stable@vger.kernel.org, Shuah Khan , linux-kselftest@vger.kernel.org X-Mailer: b4 0.16.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=2506; i=matttbe@kernel.org; h=from:subject:message-id; bh=CCaezY8L2QGxE1d8YVG+RIwjuxy2v9Yrtn18wTD4RmU=; b=owGbwMvMwCVWo/Th0Gd3rumMp9WSGLIWSBiobq1dpMO9br3wvYJVXypndW95emFXX17n6Vkv7 l56N2nnzY5SFgYxLgZZMUUW6bbI/JnPq3hLvPwsYOawMoEMYeDiFICJ6L5g+Kd8YBfTnLpnqw4I zbV2+1xjpnAnadKhoI4rU9yz5Pkffa9hZPgtnOV7NnSdhhR/b2bPK8PTMtFaiUVLpsjFG7l1XDg YxwAA X-Developer-Key: i=matttbe@kernel.org; a=openpgp; fpr=E8CB85F76877057A6E27F77AF6B7824F4269A073 When the value for a MIB counter is required, mptcp_lib_get_counter is called. It tries to use the cache, if available. If not it falls back to calling 'nstat' directly by looking at the absolute counters. That's an issue for tests that don't recreate the netns for each subtest. In this case, 'nstat -a' will look at the counters for the netns. Instead, it should look at the increment for the current test, by using the history recorded in /tmp/.nstat, if available, and not using '-a' which was dumping the absolute values. While at it, rename the previous 'hist' variable to 'cache' as it was used to look at the cache, not the nstat history. Fixes: 71388a9f331d ("selftests: mptcp: lib: get counters from nstat histor= y") Cc: stable@vger.kernel.org Reviewed-by: Geliang Tang Signed-off-by: Matthieu Baerts (NGI0) --- Cc: Shuah Khan Cc: linux-kselftest@vger.kernel.org --- tools/testing/selftests/net/mptcp/mptcp_lib.sh | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/tools/testing/selftests/net/mptcp/mptcp_lib.sh b/tools/testing= /selftests/net/mptcp/mptcp_lib.sh index da1da414c30f..b9d14647f401 100644 --- a/tools/testing/selftests/net/mptcp/mptcp_lib.sh +++ b/tools/testing/selftests/net/mptcp/mptcp_lib.sh @@ -416,19 +416,21 @@ mptcp_lib_nstat_get() { } =20 # $1: ns, $2: MIB counter -# Get the counter from the history (mptcp_lib_nstat_{init,get}()) if avail= able. -# If not, get the counter from nstat ignoring any history. +# Get the counter from the cache (mptcp_lib_nstat_{init,get}()) if availab= le. +# If not, get the counter from nstat ignoring any cache, but using the his= tory. mptcp_lib_get_counter() { local ns=3D"${1}" local counter=3D"${2}" - local hist=3D"/tmp/${ns}.out" + local cache=3D"/tmp/${ns}.out" + local hist=3D"/tmp/${ns}.nstat" local count =20 - if [[ -s "${hist}" && "${counter}" =3D=3D *"Tcp"* ]]; then - count=3D$(awk "/^${counter} / {print \$2; exit}" "${hist}") + if [[ -s "${cache}" && "${counter}" =3D=3D *"Tcp"* ]]; then + count=3D$(awk "/^${counter} / {print \$2; exit}" "${cache}") else - count=3D$(ip netns exec "${ns}" nstat -asz "${counter}" | - awk 'NR=3D=3D1 {next} {print $2}') + count=3D$(NSTAT_HISTORY=3D"${hist}" ip netns exec "${ns}" \ + nstat -sz "${counter}" | + awk 'NR=3D=3D1 {next} {print $2}') fi if [ -z "${count}" ]; then mptcp_lib_fail_if_expected_feature "${counter} counter" --=20 2.55.0 From nobody Fri Sep 25 20:48:29 2026 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 DC6FC5592F2; Tue, 8 Sep 2026 14:14:48 +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=1788876899; cv=none; b=d1AdCDwadygazcQ+wF4DGgDp8N8JLUqsJwJp88c4TmXeDepZugKmS4jC4fuvC9SJ/izcBvs37bA5Ii35LI6+gdf9lhEpCHTxApV96I/o+P/vN48kLB6EJPexOpdifCTId6zvP5604nVT/gSkYI/5AgHiRZNgTnPLe1jru3HLdOE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788876899; c=relaxed/simple; bh=OmxkKtnPfRqO9xltx7TfPbE3UpbCFtxyGe+KZ4x0R0o=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=Zl0N5cqpTtLu1oa6Glh0cjcHOthibuBbcK/l2BZ3PoD72CqRI6QlR+d4fEhANuOvJJsIXPP8Oo4bFlBBNAK7G0yADRKa3GePeJhIHCGM/NWP7pHWOZ5XqmHuymQ1cgsqPcM7kZQCjNc3c4gIzHyh0wfHW7QHhBRgBl7PJSAAJS4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=bBVvjnQC; 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="bBVvjnQC" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9497F1F00ACA; Tue, 8 Sep 2026 14:14:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1788876888; bh=J5n7TEwTvtd6j21kll5N09DmPU5cpF80L1q4Ks6P+2g=; h=From:Date:Subject:References:In-Reply-To:To:Cc; b=bBVvjnQCpYpxu+anQue11xodoKMgxZUYRkCq3tQF8AzoKI8sEUcwlwuALwdUCzNHB /KqlGBUcgscFq0cVGPTz3XpD/MUQQi3ZLJcuz5jC6UIO6dhvLsydTD5nee4dIf3ZtN MeykLkUQ8hlLJJR+szlzd+R6WB5ghyhA39Z+b7UtARmYsJd+mLJ06vdbZwE1VJ3dOV Pypvl69xYoh7b4Sq49nALBRxaMdiQ9LwRm3izxLC/6kKWSPEaHyCzbByAfPaHqOWx6 EoambclvHlMh2A+9x+PWXZpgO1FVddnE+fUI1/M70TzsfnLnC7pY4ldlONETH8q/S7 ktpR//sF3o8Ng== From: "Matthieu Baerts (NGI0)" Date: Tue, 08 Sep 2026 16:07:18 +0200 Subject: [PATCH net v2 13/15] mptcp: options: fix uninit-value in mptcp_write_data_fin Precedence: bulk X-Mailing-List: mptcp@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20260908-net-mptcp-misc-fixes-7-3-rc1-v2-13-df1de70348b6@kernel.org> References: <20260908-net-mptcp-misc-fixes-7-3-rc1-v2-0-df1de70348b6@kernel.org> In-Reply-To: <20260908-net-mptcp-misc-fixes-7-3-rc1-v2-0-df1de70348b6@kernel.org> To: Mat Martineau , Geliang Tang , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman Cc: netdev@vger.kernel.org, mptcp@lists.linux.dev, linux-kernel@vger.kernel.org, "Matthieu Baerts (NGI0)" , stable@vger.kernel.org, Kuniyuki Iwashima , Keita Morisaki , Jakub Sitnicki X-Mailer: b4 0.16.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=1873; i=matttbe@kernel.org; h=from:subject:message-id; bh=OmxkKtnPfRqO9xltx7TfPbE3UpbCFtxyGe+KZ4x0R0o=; b=owGbwMvMwCVWo/Th0Gd3rumMp9WSGLIWSBhuEKuasmeT3z4dh/f66YK3P9wJXdMmuNGgJVfur Qq3dqBCRykLgxgXg6yYIot0W2T+zOdVvCVefhYwc1iZQIYwcHEKwETK7zP8z11+s+HHhi0dPPOf TZjkK8o/Y66e55uoPxG7ix4Zqt5a28DIcPtib8jejWqsQdqHD/+9kuLN+Zz3xcc6u2lVYXMM8pX eswIA X-Developer-Key: i=matttbe@kernel.org; a=openpgp; fpr=E8CB85F76877057A6E27F77AF6B7824F4269A073 When sending a DATA_FIN without data, and because the DATA_FIN occupies 1 octet of the connection-level sequence space [1], it is then required to add a DSS mapping with specific values. If the checksum has been negotiated, it also needs to be computed, and included in the outgoing packet, and thus the initial csum data needs to be reset to 0 as well. This is no longer the case since commit cfcceb7a39fc ("tcp: shrink per-packet memset in __tcp_transmit_skb()"), because the whole ext_copy structure is no longer zeroed by default. This seems to be the only case where use_map is changed and set afterwards, so initialising the csum field only in this case, along with other fields for this specific case. Fixes: cfcceb7a39fc ("tcp: shrink per-packet memset in __tcp_transmit_skb()= ") Cc: stable@vger.kernel.org Link: https://datatracker.ietf.org/doc/html/rfc8684#section-3.3.3 [1] Link: https://sashiko.dev/#/patchset/20260812-net-next-mptcp-misc-feat-7-3-= v1-0-1905a818f6cb%40kernel.org?part=3D2 Reviewed-by: Geliang Tang Signed-off-by: Matthieu Baerts (NGI0) --- Cc: Kuniyuki Iwashima Cc: Keita Morisaki Cc: Jakub Sitnicki --- net/mptcp/options.c | 1 + 1 file changed, 1 insertion(+) diff --git a/net/mptcp/options.c b/net/mptcp/options.c index 196a46e7467d..ce0de02f5a3a 100644 --- a/net/mptcp/options.c +++ b/net/mptcp/options.c @@ -612,6 +612,7 @@ static void mptcp_write_data_fin(struct mptcp_subflow_c= ontext *subflow, ext->data_seq =3D data_fin_tx_seq; ext->subflow_seq =3D 0; ext->data_len =3D 1; + ext->csum =3D 0; } else if (ext->data_seq + ext->data_len =3D=3D data_fin_tx_seq) { /* If there's an existing DSS mapping and it is the * final mapping, DATA_FIN consumes 1 additional byte of --=20 2.55.0 From nobody Fri Sep 25 20:48:29 2026 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 338D2560AC0; Tue, 8 Sep 2026 14:14:52 +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=1788876912; cv=none; b=m8xG5ZGHg58if51r6drIW6uLYOxHmL3GA4jXJJVMB4t4P4mviWnUr8nSKd3qcj6G5GnFUGCEmeN26VHT2b+a8w7G19tOIJcbhTnfbvNrz2LneH9mBuNlGw14izw/LUWiwwZCST2tBHSNdNp9XUUayOZxcOTe+D5gfWN3A8NyMAs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788876912; c=relaxed/simple; bh=Va1cm8+jI3RJ75BNEHddwmAG2Q40V2L9shM8rRbvVzY=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=LN90M310/YS00fQwzReUnZqknVTU8/Ss81JItNY2Xu3KKf+Wuvrm4fIdp033IEFZLpbpurIUgXd3YCGeBgyrzTuUJR/pmYR0WtrOM6JQzDkO403uTviv3dH48V7hxAtkiVjptEqSi+GVBlSBY27buCF2C7vxsfsNfyDyhJ4V97A= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Nyt3BGNT; 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="Nyt3BGNT" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 666ED1F00A3F; Tue, 8 Sep 2026 14:14:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1788876890; bh=6h9xAWtPZ4ldGAVn39Gn3qvFe+0Q0ZME7hRKhcrqhVQ=; h=From:Date:Subject:References:In-Reply-To:To:Cc; b=Nyt3BGNTlB1YnIJRX2Io6NHcTGMAu9oukKM7mZKLWBy56NofJqEAWI6KZ+hPGgnFx C9/5Er/cEMXclfujIrCRLztDa2+PMByj2a06axiQ701wsE9x6HH1ZAEQ0cmmU75nHD rTldDaJF79KAJ8vCYEFjIu44+0gfRMErcrY2cy9oYqPrVMKcD1+F5VtgvDsO7+xfLB NC0j6HPSaEjMK/HspU8AobIrqKqvtIWIf7nMLW8/98XSN7UdlDjFh1i/6dUD5YYtLY cDzGBCM7SmzzRJsMLhGUFrN6JkpuQjejFlwZjgT1wiX/Dfb5sEX+MUVrW/nZOJPd9K VxlikDkcTK5mQ== From: "Matthieu Baerts (NGI0)" Date: Tue, 08 Sep 2026 16:07:19 +0200 Subject: [PATCH net v2 14/15] mptcp: being below memory limit is a likely() condition Precedence: bulk X-Mailing-List: mptcp@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20260908-net-mptcp-misc-fixes-7-3-rc1-v2-14-df1de70348b6@kernel.org> References: <20260908-net-mptcp-misc-fixes-7-3-rc1-v2-0-df1de70348b6@kernel.org> In-Reply-To: <20260908-net-mptcp-misc-fixes-7-3-rc1-v2-0-df1de70348b6@kernel.org> To: Mat Martineau , Geliang Tang , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman Cc: netdev@vger.kernel.org, mptcp@lists.linux.dev, linux-kernel@vger.kernel.org, "Matthieu Baerts (NGI0)" , stable@vger.kernel.org X-Mailer: b4 0.16.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=1095; i=matttbe@kernel.org; h=from:subject:message-id; bh=5TH+UjKSDKZpdqyAuzRYKv7QKP0HLCkVk4wX0y2bs2U=; b=owGbwMvMwCVWo/Th0Gd3rumMp9WSGLIWSBg6+C/+XuwVUebe0G15T6e80L5OYnkSx3+dneKeJ Zay4n87SlkYxLgYZMUUWaTbIvNnPq/iLfHys4CZw8oEMoSBi1MAJnIvh+EP98RCsbP6dz+sbWv/ VnI7svZ3/YWO1D3xX7NTci5cyFwazMgwye/P2nTxzI25McmNG2U3HC5Xln3c9GJiQ/YbVxmLoDR 2AA== X-Developer-Key: i=matttbe@kernel.org; a=openpgp; fpr=E8CB85F76877057A6E27F77AF6B7824F4269A073 From: Paolo Abeni The current compiler hint annotation is wrong, due to inverted logic in the previous revision of the relevant code. Fixes: e468d371180d ("mptcp: implemented OoO queue pruning") Cc: stable@vger.kernel.org Signed-off-by: Paolo Abeni Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) --- net/mptcp/protocol.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c index 302936ff456a..4309fca6b119 100644 --- a/net/mptcp/protocol.c +++ b/net/mptcp/protocol.c @@ -289,8 +289,8 @@ static void mptcp_prune_ofo_queue(struct sock *sk, */ static bool mptcp_can_ingest(const struct sock *sk) { - return unlikely(sk_rmem_alloc_get(sk) <=3D READ_ONCE(sk->sk_rcvbuf)) || - __mptcp_check_fallback(mptcp_sk(sk)); + return likely(sk_rmem_alloc_get(sk) <=3D READ_ONCE(sk->sk_rcvbuf)) || + __mptcp_check_fallback(mptcp_sk(sk)); } =20 static bool mptcp_try_rmem_schedule(struct sock *sk, const struct sk_buff = *skb) --=20 2.55.0 From nobody Fri Sep 25 20:48:29 2026 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 85C45560AD1; Tue, 8 Sep 2026 14:14:52 +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=1788876906; cv=none; b=YBKzveWTJzHFdIdV4bbBxJYNYcmpG9/k5PoT4OnDdd4WapDH+F+Hnnd9/LOPdZX6j+ZYhR8VqeSOhHIM5MDiVwfzVMgKHV5Qzlxd6oPiPQ/WeQfOfQ/XOE+7hwp+yqJz49f3bL33NoWQ89qnV7gQL7IZy8RI4HzDrhFkYa+4S/g= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788876906; c=relaxed/simple; bh=0Rf2YJvFhUDulQQ7AgAE1+fJavvfDKv+b2h+us/wCR4=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=g8Sebb1f6ybfWm6fVyJY98ql+65ltaRFnF48CHg4675Ah5UOlO8eAShtF53mkN5GtrnnfhhdY8TuvUoA885uP7xm7pV2Ns5lcnLKjJcdeamW/2YP+W3yHyrrgj/Yj/Bas4jNAc/UQJH0dwUED8aMuVGKmxup1zoxhsY6xkJyKnQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=SDurLrOp; 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="SDurLrOp" Received: by smtp.kernel.org (Postfix) with ESMTPSA id BD2CD1F00ACF; Tue, 8 Sep 2026 14:14:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1788876892; bh=9bNTr4YfhaISPP5ozmhB/lHfD4lozn0E+c2Bf6a8CwY=; h=From:Date:Subject:References:In-Reply-To:To:Cc; b=SDurLrOpJyGC8/0PKcQ7GYENjdzagDAAxEURGEqCGIjYzo2dB1pTvoP3TXYewP3GN SKQP8P0JNyY6AtrbTYqaMnV5M4nF3FkZP1qwO3XI7ygTprSCvVHfEf2L39DZ/DP79T m/K8YCqNXJL1KqLhJcesNFauyhviEtJ4S8P72fOIf9boa3UvqEwgsAVsVlK5tstFLU a9ChIJ6X+PtHP/In7n884g5Bc659IsK0hLuGTP2m2PJfM3754rVP8Ih1FKBH3vv4qW HTR6hs9/tgFKfXo65faakowSOfRcCD0SH1TfKyGNGJkvTVoCL29w3PRYhVceTCuHma mCyhvrg095zEw== From: "Matthieu Baerts (NGI0)" Date: Tue, 08 Sep 2026 16:07:20 +0200 Subject: [PATCH net v2 15/15] mptcp: avoid pruning for OoW data Precedence: bulk X-Mailing-List: mptcp@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20260908-net-mptcp-misc-fixes-7-3-rc1-v2-15-df1de70348b6@kernel.org> References: <20260908-net-mptcp-misc-fixes-7-3-rc1-v2-0-df1de70348b6@kernel.org> In-Reply-To: <20260908-net-mptcp-misc-fixes-7-3-rc1-v2-0-df1de70348b6@kernel.org> To: Mat Martineau , Geliang Tang , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman Cc: netdev@vger.kernel.org, mptcp@lists.linux.dev, linux-kernel@vger.kernel.org, "Matthieu Baerts (NGI0)" , stable@vger.kernel.org X-Mailer: b4 0.16.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=1473; i=matttbe@kernel.org; h=from:subject:message-id; bh=A8xR/5LxV2W9rnK/z18vuygkRh9g+bXMpiu5CeK5OhQ=; b=owGbwMvMwCVWo/Th0Gd3rumMp9WSGLIWSBg5zmtmLOzW9U3+EMLjdDQ9jVulZWp2QvgNITfG+ kdBx9Z0lLIwiHExyIopski3RebPfF7FW+LlZwEzh5UJZAgDF6cATKRyCsM/ZXWWZ/XHXR9e33hf p3S5N8+rqYlfnuk++8oq0Oqa2r7vFCPD8Yx7T1rqu5asWHx6a0/T7ygNsQXLlhZp3bZ6NbXacPU qVgA= X-Developer-Key: i=matttbe@kernel.org; a=openpgp; fpr=E8CB85F76877057A6E27F77AF6B7824F4269A073 From: Paolo Abeni Pruning is expansive and destructive, do it only when we expect to accept the skb triggering the cleanup. Fixes: e468d371180d ("mptcp: implemented OoO queue pruning") Cc: stable@vger.kernel.org Signed-off-by: Paolo Abeni Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) --- net/mptcp/protocol.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c index 4309fca6b119..0098e2830931 100644 --- a/net/mptcp/protocol.c +++ b/net/mptcp/protocol.c @@ -313,12 +313,6 @@ static void mptcp_data_queue_ofo(struct mptcp_sock *ms= k, struct sk_buff *skb) u64 seq, end_seq, max_seq; struct sk_buff *skb1; =20 - if (!mptcp_try_rmem_schedule(sk, skb)) { - MPTCP_INC_STATS(sock_net(sk), MPTCP_MIB_RCVPRUNED); - mptcp_drop(sk, skb); - return; - } - seq =3D MPTCP_SKB_CB(skb)->map_seq; end_seq =3D MPTCP_SKB_CB(skb)->end_seq; max_seq =3D atomic64_read(&msk->rcv_wnd_sent); @@ -335,6 +329,12 @@ static void mptcp_data_queue_ofo(struct mptcp_sock *ms= k, struct sk_buff *skb) return; } =20 + if (!mptcp_try_rmem_schedule(sk, skb)) { + MPTCP_INC_STATS(sock_net(sk), MPTCP_MIB_RCVPRUNED); + mptcp_drop(sk, skb); + return; + } + p =3D &msk->out_of_order_queue.rb_node; MPTCP_INC_STATS(sock_net(sk), MPTCP_MIB_OFOQUEUE); if (RB_EMPTY_ROOT(&msk->out_of_order_queue)) { --=20 2.55.0