From nobody Mon Aug 24 20:42:52 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 67EED39EF39; Tue, 28 Jul 2026 17:12: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=1785258744; cv=none; b=BUCDhmFRSwimOBkMs+KQYVdglsW8W2Ot+c2+9dadWbbxWk16D4T89DrAPWqblb2UaX/GQ3uIHRr1n5PPB6Zn2eCPPzQdlAphja7R3j1X/OPOX+HHa6fMsyiuCe4lgPVxZCMSSQSl2ctrGRkLBqu+f9l5laYFsVvnBul9hk+oYu0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785258744; c=relaxed/simple; bh=UWNDHPJRGFzMhPKdG8iLeGfgykpv+dSUj2VTniYS2+k=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=LGjI33QQ9O3OFedVmeVpQAfMEPW8NdKx6nIOZhIJwaViKwxpfBB5AzmlnzOHvUHAeXjIa02s4i+/n9B+7UY1WWZBhEwWEAt0NbjWHXWr7zM0kG8H0+LN9XjNkS9ZBHVwEq4tlioA60URbC7PrCWNB9diT5ppLlqqg2b8mkwbauY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=cyj+DTsr; 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="cyj+DTsr" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 891B91F00A3D; Tue, 28 Jul 2026 17:12:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1785258743; bh=8LgbWMDjQ5TxJSEXSwg1rz6pPhUFAwgEipL/hM/kl+4=; h=From:Date:Subject:References:In-Reply-To:To:Cc; b=cyj+DTsrrhiuCpwdqo4AGUxlls+nbjRzL32QKY8lFLyiCFTUWLWAK9+bDV8XJmcZv 7Vsn8HfBHZ2sxdLdTobrPKEgAiPqBCOVQhq3jyPx6ONuhJgqTs5nRKwHaRRlhdhbcn mq8r+yYyJDp+lIX0cKZ7uC4QZUlzEtDQtgILblZCXsT0c5MjbVURDbvKgjXEpQAwit 53T7MObYVjJ4QcAlCavrNjPy6Eg12o2BgF4bE0aWvhwZZEaPqtbMzc9RTHvQY8/htY wvleSXiynMHiiBF5+ksx0Iu1HMFdFHda58kQF7YE8/UuTFfI45B2y5ALLVohV0LrCN mI7o8BY/53wgA== From: "Matthieu Baerts (NGI0)" Date: Tue, 28 Jul 2026 19:11:57 +0200 Subject: [PATCH net 1/5] mptcp: avoid combining some incoming suboptions 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: <20260728-net-mptcp-misc-fixes-7-2-rc6-v1-1-f7e2d229159d@kernel.org> References: <20260728-net-mptcp-misc-fixes-7-2-rc6-v1-0-f7e2d229159d@kernel.org> In-Reply-To: <20260728-net-mptcp-misc-fixes-7-2-rc6-v1-0-f7e2d229159d@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 , Davide Caratti , Christoph Paasch X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openpgp-sha256; l=6867; i=matttbe@kernel.org; h=from:subject:message-id; bh=UWNDHPJRGFzMhPKdG8iLeGfgykpv+dSUj2VTniYS2+k=; b=owGbwMvMwCVWo/Th0Gd3rumMp9WSGLIyHr2ZcWh5+oSz+Ul6FtGPZz/7sS342fmo7DWi7OxXl jpHHt1ypqOUhUGMi0FWTJFFui0yf+bzKt4SLz8LmDmsTCBDGLg4BWAiiumMDC9YdyXPYYxu0TuT Mi8mUO6M5s55mWs+MX6Y9sxogfraKhNGhnXuP6t2yAuWOYX9OZXS12e5UnjZJqZtJZ+0nh0VNfB WZAYA X-Developer-Key: i=matttbe@kernel.org; a=openpgp; fpr=E8CB85F76877057A6E27F77AF6B7824F4269A073 Some MPTCP suboptions are mutually exclusive according to the RFC8684, but also because in different places, the code doesn't expect some combinations to be present. That's specially true for suboptions that would be present twice, but with different attributes. The new restrictions are the same as the ones applied on the output side, with mptcp_write_options. The same rules can be reused: Which options can be used together? X: mutually exclusive O: often used together C: can be used together in some cases P: could be used together but we prefer not to (optimisations) | Opt: | MPC | MPJ | DSS | ADD | RM | PRIO | FAIL | FC | |------|------|------|------|------|------|------|------|------| | MPC |------|------|------|------|------|------|------|------| | MPJ | X |------|------|------|------|------|------|------| | DSS | X | X |------|------|------|------|------|------| | ADD | X | X | P |------|------|------|------|------| | RM | C | C | C | P |------|------|------|------| | PRIO | X | C | C | C | C |------|------|------| | FAIL | X | X | C | X | X | X |------|------| | FC | X | X | X | X | X | X | X |------| | RST | X | X | X | X | X | X | O | O | |------|------|------|------|------|------|------|------|------| The only difference is with the 'P': another stack could send and ADD_ADDR with other suboptions (DSS, RM_ADDR), and this should be allowed. A point of attention is with the MP_CAPABLE: it could be used with a RM_ADDR, but there is no reason to add it with a SYN. Note that even with a 4th ACK, it doesn't seem to be useful, except when IDs are known in advance via another channel. Better not to break that. Also, in mp_opt->suboptions, there is also a bit reserved to the checksum, which can be used in an MP_CAPABLE and a DSS. Each time a DSS option can be used in parallel with another option, the checksum can be set, so the verification is combined into a new OPTIONS_MPTCP_DSS macro. Fixes: eda7acddf808 ("mptcp: Handle MPTCP TCP options") Cc: stable@vger.kernel.org Signed-off-by: Matthieu Baerts (NGI0) --- Cc: Florian Westphal Cc: Davide Caratti Cc: Christoph Paasch Note: Peter Krystad's email address is no longer valid --- net/mptcp/options.c | 55 ++++++++++++++++++++++++++++++++++++++++++++++++= ++++ net/mptcp/protocol.h | 1 + 2 files changed, 56 insertions(+) diff --git a/net/mptcp/options.c b/net/mptcp/options.c index c664023d37ba..3b8539f1c224 100644 --- a/net/mptcp/options.c +++ b/net/mptcp/options.c @@ -50,6 +50,14 @@ static void mptcp_parse_option(const struct sk_buff *skb, } } =20 + /* Only the MPC + ACK can be used with a RM_ADDR */ + if (subopt =3D=3D OPTION_MPTCP_MPC_ACK) { + if ((mp_opt->suboptions & ~OPTION_MPTCP_RM_ADDR) !=3D 0) + break; + } else if (mp_opt->suboptions !=3D 0) { + break; + } + /* Cfr RFC 8684 Section 3.3.0: * If a checksum is present but its use had * not been negotiated in the MP_CAPABLE handshake, the receiver MUST @@ -122,6 +130,11 @@ static void mptcp_parse_option(const struct sk_buff *s= kb, break; =20 case MPTCPOPT_MP_JOIN: + /* Can be used with a restricted number of other options */ + if ((mp_opt->suboptions & ~(OPTION_MPTCP_RM_ADDR | + OPTION_MPTCP_PRIO)) !=3D 0) + break; + if (opsize =3D=3D TCPOLEN_MPTCP_MPJ_SYN) { mp_opt->suboptions |=3D OPTION_MPTCP_MPJ_SYN; mp_opt->backup =3D *ptr++ & MPTCPOPT_BACKUP; @@ -153,6 +166,13 @@ static void mptcp_parse_option(const struct sk_buff *s= kb, break; =20 case MPTCPOPT_DSS: + /* Can be used with a restricted number of other options */ + if ((mp_opt->suboptions & ~(OPTION_MPTCP_ADD_ADDR | + OPTION_MPTCP_RM_ADDR | + OPTION_MPTCP_PRIO | + OPTION_MPTCP_FAIL)) !=3D 0) + break; + pr_debug("DSS\n"); ptr++; =20 @@ -234,6 +254,12 @@ static void mptcp_parse_option(const struct sk_buff *s= kb, break; =20 case MPTCPOPT_ADD_ADDR: + /* Can be used with a restricted number of other options */ + if ((mp_opt->suboptions & ~(OPTIONS_MPTCP_DSS | + OPTION_MPTCP_RM_ADDR | + OPTION_MPTCP_PRIO)) !=3D 0) + break; + mp_opt->echo =3D (*ptr++) & MPTCP_ADDR_ECHO; if (!mp_opt->echo) { if (opsize =3D=3D TCPOLEN_MPTCP_ADD_ADDR || @@ -293,6 +319,14 @@ static void mptcp_parse_option(const struct sk_buff *s= kb, break; =20 case MPTCPOPT_RM_ADDR: + /* Can be used with a restricted number of other options */ + if ((mp_opt->suboptions & ~(OPTION_MPTCP_MPC_ACK | + OPTIONS_MPTCP_MPJ | + OPTIONS_MPTCP_DSS | + OPTION_MPTCP_ADD_ADDR | + OPTION_MPTCP_PRIO)) !=3D 0) + break; + if (opsize < TCPOLEN_MPTCP_RM_ADDR_BASE + 1 || opsize > TCPOLEN_MPTCP_RM_ADDR_BASE + MPTCP_RM_IDS_MAX) break; @@ -307,6 +341,13 @@ static void mptcp_parse_option(const struct sk_buff *s= kb, break; =20 case MPTCPOPT_MP_PRIO: + /* Can be used with a restricted number of other options */ + if ((mp_opt->suboptions & ~(OPTIONS_MPTCP_MPJ | + OPTIONS_MPTCP_DSS | + OPTION_MPTCP_ADD_ADDR | + OPTION_MPTCP_RM_ADDR)) !=3D 0) + break; + if (opsize !=3D TCPOLEN_MPTCP_PRIO) break; =20 @@ -316,6 +357,10 @@ static void mptcp_parse_option(const struct sk_buff *s= kb, break; =20 case MPTCPOPT_MP_FASTCLOSE: + /* Can be used only with RST */ + if ((mp_opt->suboptions & ~OPTION_MPTCP_RST) !=3D 0) + break; + if (opsize !=3D TCPOLEN_MPTCP_FASTCLOSE) break; =20 @@ -327,6 +372,11 @@ static void mptcp_parse_option(const struct sk_buff *s= kb, break; =20 case MPTCPOPT_RST: + /* Can be used with a restricted number of other options */ + if ((mp_opt->suboptions & ~(OPTION_MPTCP_FAIL | + OPTION_MPTCP_FASTCLOSE)) !=3D 0) + break; + if (opsize !=3D TCPOLEN_MPTCP_RST) break; =20 @@ -342,6 +392,11 @@ static void mptcp_parse_option(const struct sk_buff *s= kb, break; =20 case MPTCPOPT_MP_FAIL: + /* Can be used with a restricted number of other options */ + if ((mp_opt->suboptions & ~(OPTIONS_MPTCP_DSS | + OPTION_MPTCP_RST)) !=3D 0) + break; + if (opsize !=3D TCPOLEN_MPTCP_FAIL) break; =20 diff --git a/net/mptcp/protocol.h b/net/mptcp/protocol.h index 4a2d40cd7b13..c13680d18994 100644 --- a/net/mptcp/protocol.h +++ b/net/mptcp/protocol.h @@ -37,6 +37,7 @@ OPTION_MPTCP_MPC_ACK) #define OPTIONS_MPTCP_MPJ (OPTION_MPTCP_MPJ_SYN | OPTION_MPTCP_MPJ_SYNACK = | \ OPTION_MPTCP_MPJ_ACK) +#define OPTIONS_MPTCP_DSS (OPTION_MPTCP_DSS | OPTION_MPTCP_CSUMREQD) =20 /* MPTCP option subtypes */ #define MPTCPOPT_MP_CAPABLE 0 --=20 2.53.0 From nobody Mon Aug 24 20:42:52 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 D250139FCD8; Tue, 28 Jul 2026 17:12: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=1785258747; cv=none; b=qIqcPin2EeioimAG4SiriGupLxvDDMscoqAdEBWPZr9GarWWnO0cg3MJK99Y0XFfvz4+4793ItYQ/DSi79hRfRPCr/9tjjS/xBBf1WvhH3cZGzqHviXiAl3Ku5bVQlixEUx680AIS/+5g9EwlTAeN8W+J1XhkFqnV7uXRBOz4Ag= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785258747; c=relaxed/simple; bh=5uECOOns2Y41XUYlvAgm8ybQtbEZGOYp0nbjgwLpCZU=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=jQSLtmzK8NSQEolx+cYBZOaUNeKLUWcYCiqmb+B6N03vFRXsq+A91y8U5Qd3lgVR5y5aNs990BhdVZ2L3KEhv/CiycgjRoATxPw2xJwFg3EjYxiUGlyb8x9fWxwhGO6UTuVSzlr7moX1Rv1jjeX690GgRVLUddINjXbTNeIOSIM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=odqfIDuJ; 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="odqfIDuJ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5C30D1F00A3A; Tue, 28 Jul 2026 17:12:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1785258745; bh=ddGrUJuo0FcgqMZcBeOx4dAowEcWdhsa4UnRR007kHg=; h=From:Date:Subject:References:In-Reply-To:To:Cc; b=odqfIDuJOgTR1Z4kOUKNTKFwmGfEyoP3IROfFC14dO7qTBWKRF3DFA6ASjohZWqyJ ZjuiZrxOjQs45oV+naQuurCskZX+hWUg26hhnp18A9X/+pCQQ0KRv4wTy2TWL8s+BJ RV3G/3xkYdUBNbteOJVV69j5curGee4OKZBmHt121uZXTEesQOLEibelmmg3IlUKa4 gTIWZCCragESTahwgSzgOi4UTNxoP17T00ILyRT6L2pS4zp+SQyY5/LaVXMzVVfTgi hsYHuaiCUkmT9f0wuD+9CV5/HwL3ZJmMdrJhe+pouMbdBWCuLQ2C+pd3iRPIlYp3uH s3+Cs+BJJA2XA== From: "Matthieu Baerts (NGI0)" Date: Tue, 28 Jul 2026 19:11:58 +0200 Subject: [PATCH net 2/5] mptcp: pm: fix data race in add_addr timer callback 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: <20260728-net-mptcp-misc-fixes-7-2-rc6-v1-2-f7e2d229159d@kernel.org> References: <20260728-net-mptcp-misc-fixes-7-2-rc6-v1-0-f7e2d229159d@kernel.org> In-Reply-To: <20260728-net-mptcp-misc-fixes-7-2-rc6-v1-0-f7e2d229159d@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 X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openpgp-sha256; l=1829; i=matttbe@kernel.org; h=from:subject:message-id; bh=wZ1yI/4v6nUYzHek0OESNzLU3HkX5ZJAftiZ5gXxbrA=; b=owGbwMvMwCVWo/Th0Gd3rumMp9WSGLIyHr29+rrlkdvkFz8vLmA8qdJw19T9dqeW36aoPX9XN 7kVsq7621HKwiDGxSArpsgi3RaZP/N5FW+Jl58FzBxWJpAhDFycAjCRG5IM/2t/HoxdyXtmXoQ8 t93+Lw9i2j2ESqREuRW7epcUXX1gW8rIcEN1pz77jNiL/Xyx7zY0tJgWsdQo3C3aaCIdHzvFgDO JEwA= X-Developer-Key: i=matttbe@kernel.org; a=openpgp; fpr=E8CB85F76877057A6E27F77AF6B7824F4269A073 From: Qing Luo The timer callback reads entry->retrans_times outside pm.lock to decide whether to call mptcp_pm_subflow_established(). Since mptcp_pm_announced_del_timer() can concurrently set retrans_times =3D ADD_ADDR_RETRANS_MAX under pm.lock, a race condition exists. I discovered this issue while studying the code. AI tools helped me to verify the issue can potentially happen under race conditions. Use a local 'retransmit' flag set inside pm.lock to capture whether retransmission is still possible. This ensures that mptcp_pm_subflow_established() is only called when the retransmission naturally exhausts. Fixes: 348d5c1dec60 ("mptcp: move to next addr when timeout") Cc: stable@vger.kernel.org Signed-off-by: Qing Luo Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) --- net/mptcp/pm.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/net/mptcp/pm.c b/net/mptcp/pm.c index 6afd39aea110..c71dcf887683 100644 --- a/net/mptcp/pm.c +++ b/net/mptcp/pm.c @@ -380,6 +380,7 @@ static void mptcp_pm_add_addr_timer(struct timer_list *= timer) struct mptcp_sock *msk =3D entry->sock; struct sock *sk =3D (struct sock *)msk; unsigned int timeout =3D 0; + bool retransmit; =20 pr_debug("msk=3D%p\n", msk); =20 @@ -412,14 +413,15 @@ static void mptcp_pm_add_addr_timer(struct timer_list= *timer) entry->retrans_times++; } =20 - if (entry->retrans_times < ADD_ADDR_RETRANS_MAX) + retransmit =3D entry->retrans_times < ADD_ADDR_RETRANS_MAX; + if (retransmit) timeout <<=3D entry->retrans_times; else timeout =3D 0; =20 spin_unlock_bh(&msk->pm.lock); =20 - if (entry->retrans_times =3D=3D ADD_ADDR_RETRANS_MAX) + if (!retransmit) mptcp_pm_subflow_established(msk); =20 out: --=20 2.53.0 From nobody Mon Aug 24 20:42:52 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 68A8C3A1691; Tue, 28 Jul 2026 17:12:28 +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=1785258749; cv=none; b=IkZuuanX/DTJdK/3tMYftGby6RohSlNqoJXQd/JRji9tVyTJg9mXtmOExLOZ5uNFPhyElpyhBv2kD/6ha3y2H4B6U3LNNXoTUQStqXIMSb86rZBCLBaHTk3DzEIirdddSDyudG3Og5rPIIxkcqTvjBjzNoHVPwuIfQnVzzhtHS8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785258749; c=relaxed/simple; bh=m4x0bxSy6TxsUPrJI6w5irHD5JNUjCHFJQxz6MDrmzA=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=Muj86vy31TJMO4e/2/rtFlvOMUNvDMawai74HseSoea5SO9k6J446FPoJk31SpemMMLFgAHwvlKA7gD0KKfY63m8+gGaY+oqv5wCAaTuzHw3nmYj3cGaFU/v4GKhz5JXLpmu7NKHMj5blPh03HfhowD1Bn+yNrpvsn1Rm+eerEk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Ur5/NbGA; 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="Ur5/NbGA" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D89B91F00AC4; Tue, 28 Jul 2026 17:12:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1785258748; bh=mFgngIcB30lySgR+387wwGE2NX/cftkfr18bbdf5vD0=; h=From:Date:Subject:References:In-Reply-To:To:Cc; b=Ur5/NbGAO07VVLGDkyPnUqzeHLQvxcIyzNkCKqkVr60xiUPAMc9MsvzMEUNzV5E+V 6HUG+bhs+/jFfBUgVcRa/53BB2wjmgPFsgvKaB0u0i+52I4n68QpSlbQElGZLNvqg5 tBVC7E/bDJ5khb4ruXUj9fa0vD8/KlHXmRRb21fk0Od0E5ZYcyxO38ty/m4xpBmb7S TbGOux47kD+zy2cWrJvMTaI+Qyl39/46M9mOAAiQHMrVrb+uzbrdpYp7mteWGeo7lR KM1LK98sYE+JDzx5c748ydjkEtt6EeRAqiCm7VJLE8Xr7wNLzh+531nTAB8Jop2GHi wmx9JMHXlc1yg== From: "Matthieu Baerts (NGI0)" Date: Tue, 28 Jul 2026 19:11:59 +0200 Subject: [PATCH net 3/5] selftests: mptcp: join: mark tests with data corruption as failed 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: <20260728-net-mptcp-misc-fixes-7-2-rc6-v1-3-f7e2d229159d@kernel.org> References: <20260728-net-mptcp-misc-fixes-7-2-rc6-v1-0-f7e2d229159d@kernel.org> In-Reply-To: <20260728-net-mptcp-misc-fixes-7-2-rc6-v1-0-f7e2d229159d@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.15.2 X-Developer-Signature: v=1; a=openpgp-sha256; l=1789; i=matttbe@kernel.org; h=from:subject:message-id; bh=OVf+JQzy7NpD1xgEnXRFt97nQ/5etoH6bLJALYeGoSQ=; b=owGbwMvMwCVWo/Th0Gd3rumMp9WSGLIyHr1btSHj3MK7V87v/FTvcsFu4vsrv1dEt20/EKZ8Q EijKdtBtqOUhUGMi0FWTJFFui0yf+bzKt4SLz8LmDmsTCBDGLg4BWAijgGMDP93lnp0WEzTdhR7 5tTpJdtmqKfBGl62qC9Ta/atKJW8WIb/OfPm/d+15NM7rzKuhc5R04ptdjdZf1193vPaqZVSJ2Q zmQA= X-Developer-Key: i=matttbe@kernel.org; a=openpgp; fpr=E8CB85F76877057A6E27F77AF6B7824F4269A073 From: Gang Yan check_transfer() compares the input and output files byte-by-byte using `cmp -l "$in" "$out" | while read ...`. Because the while-loop body runs in a subshell (the script sets neither lastpipe nor pipefail), the fail_test call inside it -- which sets the global ret/last_test_failed -- and the `return 1` both act on the subshell, not on check_transfer(). check_transfer() thus always falls through to `return 0`, and any data corruption affecting only the payload (leaving the subflow/PM counters untouched) is silently reported as PASS. Fixes: 8117dac3e7c3 ("selftests: mptcp: add invert check in check_transfer") Cc: stable@vger.kernel.org Assisted-by: Codex:GLM-5.2 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_join.sh | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/testing/selftests/net/mptcp/mptcp_join.sh b/tools/testin= g/selftests/net/mptcp/mptcp_join.sh index c0aeffd5cb71..7dc91fac4917 100755 --- a/tools/testing/selftests/net/mptcp/mptcp_join.sh +++ b/tools/testing/selftests/net/mptcp/mptcp_join.sh @@ -584,7 +584,7 @@ check_transfer() mv "$tmpfile" "$out" tmpfile=3D"" fi - cmp -l "$in" "$out" | while read -r i a b; do + while read -r i a b; do local sum=3D$((0${a} + 0${b})) if [ $check_invert -eq 0 ] || [ $sum -ne $((0xff)) ]; then fail_test "$what does not match (in, out):" @@ -595,7 +595,7 @@ check_transfer() else print_info "$what has inverted byte at ${i}" fi - done + done < <(cmp -l "$in" "$out") =20 return 0 } --=20 2.53.0 From nobody Mon Aug 24 20:42:52 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 4578B3A1691; Tue, 28 Jul 2026 17:12:31 +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=1785258754; cv=none; b=iunDwNEPzOS5LTFbs/XDqFZ0iPPetUV5tgi8LumTQrF138Y6TBQgaoUV16EY4FMVBMaTyYz2pdVwckfWmY4mbEIDzcVnYldBvuMXfN7An524gxoqJYXrFNq1KhFNzmotLgilrys4BhABKganFSh50+obzOcTgCPvQboNuaaN/CI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785258754; c=relaxed/simple; bh=Ee+ZUdlvPeC8oOUqX+4znofZ/G/Gth3A0llQg7KuRl8=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=qvd3BBC6EAcHNbCyAphOXhO8tYs+DVq3qlwV/TtMsLkFtyKys/ioR6vUkaIksUo9morr68yVvdofhmvmSdAi9mHoZdsZ/1kOF6OWqZ6CPI1o1tKoWgfsRtdE5jkM+msG8iPzlVpAF1J3F6RMeWQcWlSEiGbkUA+xR7tiSeEFecw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Y6FQT22U; 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="Y6FQT22U" Received: by smtp.kernel.org (Postfix) with ESMTPSA id AE9BF1F00A3A; Tue, 28 Jul 2026 17:12:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1785258751; bh=S/j1mFgvYIlP4i8duTU+YCkuh9XpJR5giL7Cj1dvYZU=; h=From:Date:Subject:References:In-Reply-To:To:Cc; b=Y6FQT22UE3pbkU+I/FajytSdaCUSuZ4ouf8EZNp5T06+jrtQOCgW+oDdq9BJDhu87 QAJCDZDDD2JbXp8IcrE0MJRUeTmaxbeXjZF/AmE34OvKmr6tFdd+mlWd7Y1CwCaDqJ XZQ/YgPoJAzfdHWdWsyWq8beJHu0OwpnyhVYovuWmEwOek1ZacbghSXnNO9QwIM+Se OLhr6gN/HSne3tkEAixWvvJPL6HCWPXbX69mGUt4aNkChJ1T4qnZzVsqtHWJPVKr5I ba51qrFDvt5s5Df0IjVylm95cE1dAN3EpxTqCKkeQb2fHE++cHsCAyYOoO5kZPB2Wj unYN8+xtVTSUg== From: "Matthieu Baerts (NGI0)" Date: Tue, 28 Jul 2026 19:12:00 +0200 Subject: [PATCH net 4/5] mptcp: fastopen: only mark MPTFO subflows with SYN 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: <20260728-net-mptcp-misc-fixes-7-2-rc6-v1-4-f7e2d229159d@kernel.org> References: <20260728-net-mptcp-misc-fixes-7-2-rc6-v1-0-f7e2d229159d@kernel.org> In-Reply-To: <20260728-net-mptcp-misc-fixes-7-2-rc6-v1-0-f7e2d229159d@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)" , Wyatt Feng , stable@vger.kernel.org, Yuan Tan , Yifan Wu , Juefei Pu , Zhengchuan Liang , Xin Liu , Ren Wei , Dmytro Shytyi X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openpgp-sha256; l=2114; i=matttbe@kernel.org; h=from:subject:message-id; bh=F0USe5Pac+45dLUx1tjf4ON3aUyhPCx9SwbxXB50mSw=; b=owGbwMvMwCVWo/Th0Gd3rumMp9WSGLIyHr2b17koakepX57nm38MF/OnzueO2qIZ0r7GepV94 N+FHJfiO0pZGMS4GGTFFFmk2yLzZz6v4i3x8rOAmcPKBDKEgYtTACZyhp2R4czL8kkLExhaP0+Z XvZ993T5Ndx615I6+3KdmFktO/ZnLWP4Z9WYMP+ycf0le94868dep+2a5l+aFqNlavLwx9W0RX9 OsgIA X-Developer-Key: i=matttbe@kernel.org; a=openpgp; fpr=E8CB85F76877057A6E27F77AF6B7824F4269A073 From: Wyatt Feng Passive TCP Fast Open accepts a valid-cookie SYN even when it carries no data. In that case the child socket's receive queue is intentionally left empty. mptcp_fastopen_subflow_synack_set_params() set is_mptfo before checking for queued SYN data. That made data-less TFO SYNs hit a WARN and, if the warning was non-fatal, left stale MPTFO state behind. The stale flag could later trigger a state-confusion bug in check_fully_established(). Only mark the subflow as MPTFO after confirming that a SYN-data skb is present. Return quietly when the receive queue is empty. Fixes: 36b122baf6a8 ("mptcp: add subflow_v(4,6)_send_synack()") Cc: stable@vger.kernel.org Reported-by: Yuan Tan Reported-by: Yifan Wu Reported-by: Juefei Pu Reported-by: Zhengchuan Liang Reported-by: Xin Liu Assisted-by: Codex:GPT-5.4 Signed-off-by: Wyatt Feng Signed-off-by: Ren Wei Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) --- Cc: Dmytro Shytyi Note: a v1 has already been shared alone on the netdev ML: https://patch.msgid.link/81f26b8fddd59ebb6cecc417fb138d9ff5214e08.1780458= 440.git.bronzed_45_vested@icloud.com --- net/mptcp/fastopen.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/net/mptcp/fastopen.c b/net/mptcp/fastopen.c index 082c46c0f50e..f717750906ff 100644 --- a/net/mptcp/fastopen.c +++ b/net/mptcp/fastopen.c @@ -24,12 +24,13 @@ void mptcp_fastopen_subflow_synack_set_params(struct mp= tcp_subflow_context *subf sk =3D subflow->conn; tp =3D tcp_sk(ssk); =20 - subflow->is_mptfo =3D 1; - + /* A valid TFO cookie does not guarantee SYN data. */ skb =3D skb_peek(&ssk->sk_receive_queue); - if (WARN_ON_ONCE(!skb)) + if (!skb) return; =20 + subflow->is_mptfo =3D 1; + /* dequeue the skb from sk receive queue */ __skb_unlink(skb, &ssk->sk_receive_queue); skb_ext_reset(skb); --=20 2.53.0 From nobody Mon Aug 24 20:42:52 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 5179D39EF23; Tue, 28 Jul 2026 17:12:34 +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=1785258755; cv=none; b=lrUA2+wWSFhWOSIOSKZDLoRlqCfsgh+OSM/cseqFiocPJbEFc1mZ0Sr8hBVgwJ+7ZpM7nQQ1lkW1qU+Baas2/Bn8WDcM3+D7XUFL73kGcrNoh0HuovyzWAz9cCS7lwCVUDAkD7E9FiadDm+bodH2tZ2i2QDhvgh/c5dHOhBiTD0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785258755; c=relaxed/simple; bh=95laPrOyZSSO2MaKvtBXnM4BRisS7e05Qe6xBWMwGB4=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=Ah+1ogJ0xlavJm1kmZNS8gfWfGBfh8iyTwyd3LCn6dXJXhxglw5v3Aw2F9R7UIjgBN8J2AU8MG8AAGTNnhIIl3DMse/wbHBlH9ksoUdsbTEvVnte88WEI0G3Y2j8gGK6IGRMkUnmXaeRl7Fd+FNjGa2oKC0qQ4KHGPxAHNDzUi0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Tl6x6V7U; 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="Tl6x6V7U" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 447771F00A3E; Tue, 28 Jul 2026 17:12:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1785258754; bh=u+AZSEUgWhE7D0opgqssDSdlP1ic8S4Y/lQMRdKfPpQ=; h=From:Date:Subject:References:In-Reply-To:To:Cc; b=Tl6x6V7UlymHMlPBeGcqKgc5LuaccS90SYjsuDVR21vB9v3Cr1xlKcORHr/J2obSB xsQBH8GopcsDsSmilveK04UfnviET3cN/0imp3c2lRgkdHtkvNThuQi1a7GpLT1M30 iWWSKnPbNg9Qz8R/inVIJ3JsiieIltDQf3hn4pOaXW9V9Be14F/kW8DKuSfaxCXWGv 10w13m4r6lIpbUtkKYziQDRNOfMQ4EQ2wPow9Fa3OA4/gebyKyi2XkngLXu2erl/Lc muzfO+xFCi1NdNW3ILzDL9lLMY6A7IsomzdRRZWKKj1IPzsc/rnVCsj14B7R2kYcaC H8y5sckhFRlgA== From: "Matthieu Baerts (NGI0)" Date: Tue, 28 Jul 2026 19:12:01 +0200 Subject: [PATCH net 5/5] mptcp: reclaim forward-allocated memory on RX path errors 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: <20260728-net-mptcp-misc-fixes-7-2-rc6-v1-5-f7e2d229159d@kernel.org> References: <20260728-net-mptcp-misc-fixes-7-2-rc6-v1-0-f7e2d229159d@kernel.org> In-Reply-To: <20260728-net-mptcp-misc-fixes-7-2-rc6-v1-0-f7e2d229159d@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.15.2 X-Developer-Signature: v=1; a=openpgp-sha256; l=1239; i=matttbe@kernel.org; h=from:subject:message-id; bh=9MruphuE0mDyM48vy8r+FyoIyzzsuXdFdAn+ZcRkOGE=; b=owGbwMvMwCVWo/Th0Gd3rumMp9WSGLIyHr2/vyPl4MGgvJ7bgVX6h19ybnRJkMo6dWHt7f4dA V6fOL3TO0pZGMS4GGTFFFmk2yLzZz6v4i3x8rOAmcPKBDKEgYtTACai3cPIcFgjriXW1muL9o9J Sznvdm9fPmfeJ4c/DE/te+rjV2e4rWFkuH+Xw+Hil4IjPzUrP15ve+HrHHC7cxXzSd9t+rNcfaY WMwAA X-Developer-Key: i=matttbe@kernel.org; a=openpgp; fpr=E8CB85F76877057A6E27F77AF6B7824F4269A073 From: Paolo Abeni After commit 9db5b3cec4ec ("mptcp: borrow forward memory from subflow"), errors in the receive path prior to queueing skbs into the receive queue do not trigger forward-allocated memory reclaiming. Prevent forward memory from growing unboundedly in pathological drop scenarios by explicitly reclaiming memory when skbs are dropped. Fixes: 9db5b3cec4ec ("mptcp: borrow forward memory from subflow") 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 | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c index ca644ec53eed..47eaf64a54ba 100644 --- a/net/mptcp/protocol.c +++ b/net/mptcp/protocol.c @@ -149,6 +149,13 @@ struct sock *__mptcp_nmpc_sk(struct mptcp_sock *msk) =20 static void mptcp_drop(struct sock *sk, struct sk_buff *skb) { + /* + * The skb forward memory was already transferred to sk by + * mptcp_borrow_fwdmem(), even before setting the destructor. + */ + if (!skb->destructor) + sk_mem_reclaim(sk); + sk_drops_skbadd(sk, skb); __kfree_skb(skb); } --=20 2.53.0