From nobody Sun Dec 14 06:42:55 2025 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 B23F81D86FF; Sat, 29 Nov 2025 16:56:21 +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=1764435381; cv=none; b=nX+jJVZQmyKHCMKI/UQ90s0E+WyL0kG5F7oiNi/5cGSoHhzRWYJL/ws9OA/TgFuch9nyjNiu/67HPviQb0X9RraZYAsqqDy53OdxEf9Koa4DRi6kOfPbd7ZwBJ0s3AhqKoznqSieNLNrRbRAzTcAXbzMltUE4dVLEuLpN71Gju8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764435381; c=relaxed/simple; bh=0GdDtXM/1+B6k7UUo7dB+VnYSEXafjU1RL5syDr24WE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=lUdiLufm2tGHR1qZYM71xKfk8dHaoJkhepQNzYiW8mDmcLWfkPreywAnAi4uDtiFXqY2QqWeDanG13of6w7tmzfKTJ+6DTe/qS52ryChjQZYArNrWPhV4GyhSOCth6sASojojlZenIMoeLfgiDe1PreVyrXtF+3mvpha0O/B84Q= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=MUEzpSHd; 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="MUEzpSHd" Received: by smtp.kernel.org (Postfix) with ESMTPSA id DA5DDC4CEF7; Sat, 29 Nov 2025 16:56:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1764435381; bh=0GdDtXM/1+B6k7UUo7dB+VnYSEXafjU1RL5syDr24WE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=MUEzpSHdA2boHcrel5LPA3iROOB04k2b8hKdXVClaBzxuDH8hNtSjGbjSlBFs+gsr 9PULAyz3lYIHeohRb/BcmGVCHcDOfkz9NRRyJrAtK2P8bEHZXwhjO/NPWwVZwXE8s9 TjL3fmnx4OaI72C7KDX4+QLGH2DqnqPaBln9c40c/8ksK58WdnmXWQl70lfgYJULIS +SMRlqkCVuF2VVAyuMknndgOeAes9SROSCIMlHA2yQb8zZA8WT5i6jgn7NlRspcz/S c9MhDvVmIo5tZR/vYLYomzxjMDjX4iJwb+IXd7gkj9vDYUeNMxNnhHle1c+sMlYkm8 ghc/IP5POIipQ== From: "Matthieu Baerts (NGI0)" To: stable@vger.kernel.org, gregkh@linuxfoundation.org Cc: MPTCP Upstream , Paolo Abeni , Geliang Tang , "Matthieu Baerts (NGI0)" , Jakub Kicinski Subject: [PATCH 6.1.y] mptcp: fix duplicate reset on fastclose Date: Sat, 29 Nov 2025 17:56:13 +0100 Message-ID: <20251129165612.2125498-2-matttbe@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <2025112411-cytoplasm-virus-b6dd@gregkh> References: <2025112411-cytoplasm-virus-b6dd@gregkh> Precedence: bulk X-Mailing-List: mptcp@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=4317; i=matttbe@kernel.org; h=from:subject; bh=cGNWMSBW/qJlyiX/imKPUWN5+pXiJEhnctpgSxNwTt0=; b=owGbwMvMwCVWo/Th0Gd3rumMp9WSGDK1VdeunP1XomrC74dpdb0K96pkDVrWHj6Vtnq1vNXXx WLrg2ROdJSyMIhxMciKKbJIt0Xmz3xexVvi5WcBM4eVCWQIAxenAEzkWxzDX6kPgtJzU3acOFk1 WS9j5Rptx6871m9L0Mhk2Os/KZnddx8jw2uNtV3CNz4wFGRM2MIuM+krR/C+mSd23D9+ZuVMoTi dA/wA X-Developer-Key: i=matttbe@kernel.org; a=openpgp; fpr=E8CB85F76877057A6E27F77AF6B7824F4269A073 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Paolo Abeni commit ae155060247be8dcae3802a95bd1bdf93ab3215d upstream. The CI reports sporadic failures of the fastclose self-tests. The root cause is a duplicate reset, not carrying the relevant MPTCP option. In the failing scenario the bad reset is received by the peer before the fastclose one, preventing the reception of the latter. Indeed there is window of opportunity at fastclose time for the following race: mptcp_do_fastclose __mptcp_close_ssk __tcp_close() tcp_set_state() [1] tcp_send_active_reset() [2] After [1] the stack will send reset to in-flight data reaching the now closed port. Such reset may race with [2]. Address the issue explicitly sending a single reset on fastclose before explicitly moving the subflow to close status. Fixes: d21f83485518 ("mptcp: use fastclose on more edge scenarios") Cc: stable@vger.kernel.org Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/596 Signed-off-by: Paolo Abeni Reviewed-by: Geliang Tang Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20251118-net-mptcp-misc-fixes-6-18-rc6-v1-6-= 806d3781c95f@kernel.org Signed-off-by: Jakub Kicinski [ Conflicts in protocol.c, because commit bbd49d114d57 ("mptcp: consolidate transition to TCP_CLOSE in mptcp_do_fastclose()") is not in this version. It introduced a new line in the context. The same modification can still be applied. Also, tcp_send_active_reset() doesn't take a 3rd argument (sk_rst_reason) in this version, see commit 5691276b39da ("rstreason: prepare for active reset"). This argument is only helpful for tracing, it is fine to drop it. ] Signed-off-by: Matthieu Baerts (NGI0) --- net/mptcp/protocol.c | 34 +++++++++++++++++++++------------- 1 file changed, 21 insertions(+), 13 deletions(-) diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c index c4858776e2b8..e2908add97d3 100644 --- a/net/mptcp/protocol.c +++ b/net/mptcp/protocol.c @@ -2440,7 +2440,6 @@ bool __mptcp_retransmit_pending_data(struct sock *sk) =20 /* flags for __mptcp_close_ssk() */ #define MPTCP_CF_PUSH BIT(1) -#define MPTCP_CF_FASTCLOSE BIT(2) =20 /* be sure to send a reset only if the caller asked for it, also * clean completely the subflow status when the subflow reaches @@ -2451,7 +2450,7 @@ static void __mptcp_subflow_disconnect(struct sock *s= sk, unsigned int flags) { if (((1 << ssk->sk_state) & (TCPF_CLOSE | TCPF_LISTEN)) || - (flags & MPTCP_CF_FASTCLOSE)) { + subflow->send_fastclose) { /* The MPTCP code never wait on the subflow sockets, TCP-level * disconnect should never fail */ @@ -2498,14 +2497,8 @@ static void __mptcp_close_ssk(struct sock *sk, struc= t sock *ssk, =20 lock_sock_nested(ssk, SINGLE_DEPTH_NESTING); =20 - if ((flags & MPTCP_CF_FASTCLOSE) && !__mptcp_check_fallback(msk)) { - /* be sure to force the tcp_close path - * to generate the egress reset - */ - ssk->sk_lingertime =3D 0; - sock_set_flag(ssk, SOCK_LINGER); - subflow->send_fastclose =3D 1; - } + if (subflow->send_fastclose && ssk->sk_state !=3D TCP_CLOSE) + tcp_set_state(ssk, TCP_CLOSE); =20 need_push =3D (flags & MPTCP_CF_PUSH) && __mptcp_retransmit_pending_data(= sk); if (!dispose_it) { @@ -2794,9 +2787,24 @@ static void mptcp_do_fastclose(struct sock *sk) struct mptcp_subflow_context *subflow, *tmp; struct mptcp_sock *msk =3D mptcp_sk(sk); =20 - mptcp_for_each_subflow_safe(msk, subflow, tmp) - __mptcp_close_ssk(sk, mptcp_subflow_tcp_sock(subflow), - subflow, MPTCP_CF_FASTCLOSE); + /* Explicitly send the fastclose reset as need */ + if (__mptcp_check_fallback(msk)) + return; + + mptcp_for_each_subflow_safe(msk, subflow, tmp) { + struct sock *ssk =3D mptcp_subflow_tcp_sock(subflow); + + lock_sock(ssk); + + /* Some subflow socket states don't allow/need a reset.*/ + if ((1 << ssk->sk_state) & (TCPF_LISTEN | TCPF_CLOSE)) + goto unlock; + + subflow->send_fastclose =3D 1; + tcp_send_active_reset(ssk, ssk->sk_allocation); +unlock: + release_sock(ssk); + } } =20 static void mptcp_worker(struct work_struct *work) --=20 2.51.0