From patchwork Tue Oct 8 11:04:52 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Matthieu Baerts (NGI0)" X-Patchwork-Id: 13826244 X-Patchwork-Delegate: kuba@kernel.org 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 579EC1DED6A; Tue, 8 Oct 2024 11:05:22 +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=1728385522; cv=none; b=j4pRhhyJ1AjiOdZyiOvryRPVL48xFcAXBp7gG8fswH64V8XiMhVKppwlEx/Ki9bnXf9FNKNqKvc5vvup0Em3poFco+QrsqmYzwCjWuQE/4mcP/dPoIIDk9E2M6MJ0YpcAeIfnQTTua0us/ZNuwBu4VEk2Hs/qo34JVGPMUBxvDs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1728385522; c=relaxed/simple; bh=A2HdqGarMviolXo6xME/InIGGT7YD0MGGuHimqu8Nzs=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=ukTIP/WLSi8Awp+bWsDK6YM0qhxpjeQi0Xssnrj116RMHSVIzkooYQcsXH87YrvJhznJdEb90r3gQ67kbjcf1LREhEhJz0xduGB+Drh8C+TEiOFdEieccpe4zjGLUR95FCMMaQZQtNC2H27Wt2l0hwdm+7jnJ3Gha8RVhPjNAFY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=TxzOd6LQ; 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="TxzOd6LQ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 34F46C4CECF; Tue, 8 Oct 2024 11:05:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1728385521; bh=A2HdqGarMviolXo6xME/InIGGT7YD0MGGuHimqu8Nzs=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=TxzOd6LQt2x4rnnQkUjywDwj4bskj96KU3Nqv4wSjG2SPc1tmUyw0+abpnPKH44Uf dfAN/F0PaBvmZlQOGhMrw/LdZrOunI79Ts2HKZjePQ3NODhf9Ult6IsW7S+u6m+3Fl L+EfnTDuvrqadEbcl2Sno9cGmmZteFsvfDriKhzD7yj96saibhYrz4OTPL8v7WBzjN 74W5bRtLh7k2bVX6F4qNHJ0JzFr4bPOBmhwBf/Z5xHCCi5zX0rBCjvU0hpqSw+nitM zGNCtZGhBAphbr7cNepCYMwVoOlLIVmLruvjWUYJUYg1E9/pdFgJmDsMY4asAGJk4d ThZjqLNw/C7dg== From: "Matthieu Baerts (NGI0)" Date: Tue, 08 Oct 2024 13:04:52 +0200 Subject: [PATCH net 1/4] mptcp: handle consistently DSS corruption Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Message-Id: <20241008-net-mptcp-fallback-fixes-v1-1-c6fb8e93e551@kernel.org> References: <20241008-net-mptcp-fallback-fixes-v1-0-c6fb8e93e551@kernel.org> In-Reply-To: <20241008-net-mptcp-fallback-fixes-v1-0-c6fb8e93e551@kernel.org> To: mptcp@lists.linux.dev, Mat Martineau , Geliang Tang , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Florian Westphal , David Ahern Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org, "Matthieu Baerts (NGI0)" , stable@vger.kernel.org X-Mailer: b4 0.14.2 X-Developer-Signature: v=1; a=openpgp-sha256; l=4412; i=matttbe@kernel.org; h=from:subject:message-id; bh=Ar8yJiqR2tNOyRSbUu1uGLaq6oBCeCbAzb7WpBCXHa0=; b=owEBbQKS/ZANAwAIAfa3gk9CaaBzAcsmYgBnBRHr/LT/srZ/B0MzlsZyUk8mc7cGrilPA7avr ZCGfYTU5ZeJAjMEAAEIAB0WIQToy4X3aHcFem4n93r2t4JPQmmgcwUCZwUR6wAKCRD2t4JPQmmg cw4pEAC0shr8hB1xTuDc4LWgX6YegkDVAwZYlvreFeRDlmYCbwTqi6U4LG6QnxaxWBADtj775vb h032rneTSseEzS1xpBEgiMPJYqiUqRKjv+pB02tnv3Nx8WBXhOC9nkjQjrqMnpzoDBXiT0p0AO1 sigWswWQBHDA1APasmqjv/kbk/j46R2YvHmTbdPT0v6beAiEFO63KvTzloGVzOJECc9lnOaIg2R 4iF0N8m5dLlOsV3gJzCqDUH8M0pEs1+R0rL/14CdCuKDUunpQl4wIWGKFaNS7lFiBDh5pMewiCO YJzyXVn3u8+frsEKHY4V9qrxXzOv89vSmSbVh2sFJPgPrjJ44tIE2EpE98Y6BkPU90QoYDew0gc KDkpR0y69NON0/9bKd+23GxtBdl7DyJFrmQdq7GRbS0ulcvoXuTbBN1hja3jF4Rio6mI//4jeIj pdC45KAjvjFDOgr4k8rHAhMB4EYxNK8dXI37E0WejXJRDHzgAc5Z+53nBnStw5mqSykJ4qCkHMd qdGFrki1xwJjsdfo4xl+W3mbg9yyMFVS8kQVnQV0uK1DBnpmf6wP0Ist3NOEEyvawONSzm+DlV/ jFZbUbtcymfdBchAVoWgcD6j6cYJ0xHPeGZci3tv8Ql1t/K/ugBzsqSC5jXuveB8lZm+jXbVLHH IvPj7/2ufWSMKHg== X-Developer-Key: i=matttbe@kernel.org; a=openpgp; fpr=E8CB85F76877057A6E27F77AF6B7824F4269A073 X-Patchwork-Delegate: kuba@kernel.org From: Paolo Abeni Bugged peer implementation can send corrupted DSS options, consistently hitting a few warning in the data path. Use DEBUG_NET assertions, to avoid the splat on some builds and handle consistently the error, dumping related MIBs and performing fallback and/or reset according to the subflow type. Fixes: 6771bfd9ee24 ("mptcp: update mptcp ack sequence from work queue") Cc: stable@vger.kernel.org Signed-off-by: Paolo Abeni Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) --- net/mptcp/mib.c | 2 ++ net/mptcp/mib.h | 2 ++ net/mptcp/protocol.c | 24 +++++++++++++++++++++--- net/mptcp/subflow.c | 4 +++- 4 files changed, 28 insertions(+), 4 deletions(-) diff --git a/net/mptcp/mib.c b/net/mptcp/mib.c index 38c2efc82b948d9afd35c4d5bcd45d9e5422a88d..ad88bd3c58dffed8335eedb43ca6290418e3c4f4 100644 --- a/net/mptcp/mib.c +++ b/net/mptcp/mib.c @@ -32,6 +32,8 @@ static const struct snmp_mib mptcp_snmp_list[] = { SNMP_MIB_ITEM("MPJoinSynTxBindErr", MPTCP_MIB_JOINSYNTXBINDERR), SNMP_MIB_ITEM("MPJoinSynTxConnectErr", MPTCP_MIB_JOINSYNTXCONNECTERR), SNMP_MIB_ITEM("DSSNotMatching", MPTCP_MIB_DSSNOMATCH), + SNMP_MIB_ITEM("DSSCorruptionFallback", MPTCP_MIB_DSSCORRUPTIONFALLBACK), + SNMP_MIB_ITEM("DSSCorruptionReset", MPTCP_MIB_DSSCORRUPTIONRESET), SNMP_MIB_ITEM("InfiniteMapTx", MPTCP_MIB_INFINITEMAPTX), SNMP_MIB_ITEM("InfiniteMapRx", MPTCP_MIB_INFINITEMAPRX), SNMP_MIB_ITEM("DSSNoMatchTCP", MPTCP_MIB_DSSTCPMISMATCH), diff --git a/net/mptcp/mib.h b/net/mptcp/mib.h index c8ffe18a872217afa24e3af212fe90a3fb8d1c7f..3206cdda8bb1067f9a8354fd45deed86b67ac7da 100644 --- a/net/mptcp/mib.h +++ b/net/mptcp/mib.h @@ -27,6 +27,8 @@ enum linux_mptcp_mib_field { MPTCP_MIB_JOINSYNTXBINDERR, /* Not able to bind() the address when sending a SYN + MP_JOIN */ MPTCP_MIB_JOINSYNTXCONNECTERR, /* Not able to connect() when sending a SYN + MP_JOIN */ MPTCP_MIB_DSSNOMATCH, /* Received a new mapping that did not match the previous one */ + MPTCP_MIB_DSSCORRUPTIONFALLBACK,/* DSS corruption detected, fallback */ + MPTCP_MIB_DSSCORRUPTIONRESET, /* DSS corruption detected, MPJ subflow reset */ MPTCP_MIB_INFINITEMAPTX, /* Sent an infinite mapping */ MPTCP_MIB_INFINITEMAPRX, /* Received an infinite mapping */ MPTCP_MIB_DSSTCPMISMATCH, /* DSS-mapping did not map with TCP's sequence numbers */ diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c index c2317919fc148a67a81ded795359bd613c9b0dff..6d0e201c3eb26aa6ca0ff27e5a65cb6f911012f2 100644 --- a/net/mptcp/protocol.c +++ b/net/mptcp/protocol.c @@ -620,6 +620,18 @@ static bool mptcp_check_data_fin(struct sock *sk) return ret; } +static void mptcp_dss_corruption(struct mptcp_sock *msk, struct sock *ssk) +{ + if (READ_ONCE(msk->allow_infinite_fallback)) { + MPTCP_INC_STATS(sock_net(ssk), + MPTCP_MIB_DSSCORRUPTIONFALLBACK); + mptcp_do_fallback(ssk); + } else { + MPTCP_INC_STATS(sock_net(ssk), MPTCP_MIB_DSSCORRUPTIONRESET); + mptcp_subflow_reset(ssk); + } +} + static bool __mptcp_move_skbs_from_subflow(struct mptcp_sock *msk, struct sock *ssk, unsigned int *bytes) @@ -692,10 +704,16 @@ static bool __mptcp_move_skbs_from_subflow(struct mptcp_sock *msk, moved += len; seq += len; - if (WARN_ON_ONCE(map_remaining < len)) - break; + if (unlikely(map_remaining < len)) { + DEBUG_NET_WARN_ON_ONCE(1); + mptcp_dss_corruption(msk, ssk); + } } else { - WARN_ON_ONCE(!fin); + if (unlikely(!fin)) { + DEBUG_NET_WARN_ON_ONCE(1); + mptcp_dss_corruption(msk, ssk); + } + sk_eat_skb(ssk, skb); done = true; } diff --git a/net/mptcp/subflow.c b/net/mptcp/subflow.c index 1040b3b9696b74b12c1f8c027e5a323c558900f0..e1046a696ab5c79a2cef79870eb79637b432fcd5 100644 --- a/net/mptcp/subflow.c +++ b/net/mptcp/subflow.c @@ -975,8 +975,10 @@ static bool skb_is_fully_mapped(struct sock *ssk, struct sk_buff *skb) unsigned int skb_consumed; skb_consumed = tcp_sk(ssk)->copied_seq - TCP_SKB_CB(skb)->seq; - if (WARN_ON_ONCE(skb_consumed >= skb->len)) + if (unlikely(skb_consumed >= skb->len)) { + DEBUG_NET_WARN_ON_ONCE(1); return true; + } return skb->len - skb_consumed <= subflow->map_data_len - mptcp_subflow_get_map_offset(subflow); From patchwork Tue Oct 8 11:04:53 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Matthieu Baerts (NGI0)" X-Patchwork-Id: 13826245 X-Patchwork-Delegate: kuba@kernel.org 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 8F4EA1DF73C; Tue, 8 Oct 2024 11:05:25 +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=1728385525; cv=none; b=fZ/DbOb/hxzMzS4P9bBdfHsPD+oYxZPxV09QcSwIlhIBXKT5nh2aZSTQfdu5hYW/3LGWjiC7RnTaPOmk42c/uUqVy4OLi25o0VcO+TWQQRTR4OLhhchlOJRFXek49YMc1UByHwWXrJ8nznDKq6rbeA6734N15EHVG0nNC3uZap8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1728385525; c=relaxed/simple; bh=JUeIH5zegFcFhRZG19MgrhERP87CR/vq1wRfqCUX1io=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=mq4A+/YjpqjOOGHI6ObNh+X2cwHqolroYUhs+R4RrzfMdgDT6H46zntMKXUlg1JM4XmDh3V2+x+7/CLVBQ3rs0RQT9vUffCwX0TRzWP2JziAStQYUmsKykDhqBOLT+KvsuJcCmorhlzrwE7AeeyqNX8Vf6srsoVPhgvsVk4qjBY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=hbRRkg2R; 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="hbRRkg2R" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 520ABC4CECD; Tue, 8 Oct 2024 11:05:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1728385525; bh=JUeIH5zegFcFhRZG19MgrhERP87CR/vq1wRfqCUX1io=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=hbRRkg2RIwXWRJTfjM/PESh7gWlVF/88lyQJ4NFKEcA0jqTVnLVILGA+wLOOhQlaI WFsdJxlKBrBH1yiaYQH3vVsMESvWQJZB98Rv/ZoELvcyFZl8GQeacfVJyEqIMx/vUj JgVp4pecx/uGgJboW9yuAXDYs/EtZU493aGQdlLJEl2/E/TndYf+Am0YD0oVjQ8jma 8/K13BJE3j2s3Lj+8XIgELNDqyKlAzrB0xCZrq9K2CrrN0EapxMcR58H2Dy7eQ9qD3 ulx/TkXUPDTrY0UY3S5Nk32VlclmHKGsJuDYfRYrcjASbHiwgoJqf9ZAjEb6ydr04q +46i+hQyS5a8g== From: "Matthieu Baerts (NGI0)" Date: Tue, 08 Oct 2024 13:04:53 +0200 Subject: [PATCH net 2/4] tcp: fix mptcp DSS corruption due to large pmtu xmit Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Message-Id: <20241008-net-mptcp-fallback-fixes-v1-2-c6fb8e93e551@kernel.org> References: <20241008-net-mptcp-fallback-fixes-v1-0-c6fb8e93e551@kernel.org> In-Reply-To: <20241008-net-mptcp-fallback-fixes-v1-0-c6fb8e93e551@kernel.org> To: mptcp@lists.linux.dev, Mat Martineau , Geliang Tang , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Florian Westphal , David Ahern Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org, "Matthieu Baerts (NGI0)" , stable@vger.kernel.org, syzbot+d1bff73460e33101f0e7@syzkaller.appspotmail.com X-Mailer: b4 0.14.2 X-Developer-Signature: v=1; a=openpgp-sha256; l=6794; i=matttbe@kernel.org; h=from:subject:message-id; bh=08Djw5KmknESCYUZa45JPNWB5+Ktf0j/4F/fsi+a3I4=; b=owEBbQKS/ZANAwAIAfa3gk9CaaBzAcsmYgBnBRHrObNJewAzRZm+oNVZLnvSXKeQHRK0yRJOA VEF+tRR9YKJAjMEAAEIAB0WIQToy4X3aHcFem4n93r2t4JPQmmgcwUCZwUR6wAKCRD2t4JPQmmg c5jEEADvREjW/040Sose9rJdlKMIQZhhb/PLINf/pfFyGnZPTEhEBW/w75bFMZrMCFdnfKRVvvl MWnSE8K8dKraLep+fjc4TdvbItDjZ5tdIXMzBCc2o1g0Q37o76v/kAJLS+TlOCK8jFd/ksNYk/+ dOOSYc5d4pppCauB6nn7dHblVlii/GKNgUE7juz5G28e/pIguX7gu1DA9OyHpP4s8ZLPKktrKCb MHrRvLhDr+gJAuzXFhzMw2x5BDoi+jGZb0ySpJ0ul5EpSyx114F46Fx0cJHumol0yUEGUcybsWp qaPRLpEHCO1vZDlukJ86lvpZD16s8/MqPtc6jS26ymFDyUYD3emezZkLtJJJPhhi93wmwVlRGfV KlradV3PFmSjtQvTA6Ppx92ACFPCKPif56X53puYYhpDK4s76hpbXbCBCFlKEP3KDVeY16krbsi IALQJNkLpVV6aVXhaHZ9i1YPnshmAcgYSuDDipNEpFm9LY3ofKSxBh0C55UCi6Urh7jzsQ66xmr I/n7dTeRfEsOmsxPUR0zCK2Pg4mSapOHiW5MeIffKaLdry+1s5E8151HFrafWULzpCQNEFwjJ3X 1S+shzVVPsIzzWWGoL2Ke/Juryltt6lLmdfmjh9wfy7N33YON2+DOm0jjS66bgqE2Ka/RCiJIu/ IdEkWdJHMrZFRaQ== X-Developer-Key: i=matttbe@kernel.org; a=openpgp; fpr=E8CB85F76877057A6E27F77AF6B7824F4269A073 X-Patchwork-Delegate: kuba@kernel.org From: Paolo Abeni Syzkaller was able to trigger a DSS corruption: TCP: request_sock_subflow_v4: Possible SYN flooding on port [::]:20002. Sending cookies. ------------[ cut here ]------------ WARNING: CPU: 0 PID: 5227 at net/mptcp/protocol.c:695 __mptcp_move_skbs_from_subflow+0x20a9/0x21f0 net/mptcp/protocol.c:695 Modules linked in: CPU: 0 UID: 0 PID: 5227 Comm: syz-executor350 Not tainted 6.11.0-syzkaller-08829-gaf9c191ac2a0 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:__mptcp_move_skbs_from_subflow+0x20a9/0x21f0 net/mptcp/protocol.c:695 Code: 0f b6 dc 31 ff 89 de e8 b5 dd ea f5 89 d8 48 81 c4 50 01 00 00 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc e8 98 da ea f5 90 <0f> 0b 90 e9 47 ff ff ff e8 8a da ea f5 90 0f 0b 90 e9 99 e0 ff ff RSP: 0018:ffffc90000006db8 EFLAGS: 00010246 RAX: ffffffff8ba9df18 RBX: 00000000000055f0 RCX: ffff888030023c00 RDX: 0000000000000100 RSI: 00000000000081e5 RDI: 00000000000055f0 RBP: 1ffff110062bf1ae R08: ffffffff8ba9cf12 R09: 1ffff110062bf1b8 R10: dffffc0000000000 R11: ffffed10062bf1b9 R12: 0000000000000000 R13: dffffc0000000000 R14: 00000000700cec61 R15: 00000000000081e5 FS: 000055556679c380(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020287000 CR3: 0000000077892000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: move_skbs_to_msk net/mptcp/protocol.c:811 [inline] mptcp_data_ready+0x29c/0xa90 net/mptcp/protocol.c:854 subflow_data_ready+0x34a/0x920 net/mptcp/subflow.c:1490 tcp_data_queue+0x20fd/0x76c0 net/ipv4/tcp_input.c:5283 tcp_rcv_established+0xfba/0x2020 net/ipv4/tcp_input.c:6237 tcp_v4_do_rcv+0x96d/0xc70 net/ipv4/tcp_ipv4.c:1915 tcp_v4_rcv+0x2dc0/0x37f0 net/ipv4/tcp_ipv4.c:2350 ip_protocol_deliver_rcu+0x22e/0x440 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x341/0x5f0 net/ipv4/ip_input.c:233 NF_HOOK+0x3a4/0x450 include/linux/netfilter.h:314 NF_HOOK+0x3a4/0x450 include/linux/netfilter.h:314 __netif_receive_skb_one_core net/core/dev.c:5662 [inline] __netif_receive_skb+0x2bf/0x650 net/core/dev.c:5775 process_backlog+0x662/0x15b0 net/core/dev.c:6107 __napi_poll+0xcb/0x490 net/core/dev.c:6771 napi_poll net/core/dev.c:6840 [inline] net_rx_action+0x89b/0x1240 net/core/dev.c:6962 handle_softirqs+0x2c5/0x980 kernel/softirq.c:554 do_softirq+0x11b/0x1e0 kernel/softirq.c:455 __local_bh_enable_ip+0x1bb/0x200 kernel/softirq.c:382 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:919 [inline] __dev_queue_xmit+0x1764/0x3e80 net/core/dev.c:4451 dev_queue_xmit include/linux/netdevice.h:3094 [inline] neigh_hh_output include/net/neighbour.h:526 [inline] neigh_output include/net/neighbour.h:540 [inline] ip_finish_output2+0xd41/0x1390 net/ipv4/ip_output.c:236 ip_local_out net/ipv4/ip_output.c:130 [inline] __ip_queue_xmit+0x118c/0x1b80 net/ipv4/ip_output.c:536 __tcp_transmit_skb+0x2544/0x3b30 net/ipv4/tcp_output.c:1466 tcp_transmit_skb net/ipv4/tcp_output.c:1484 [inline] tcp_mtu_probe net/ipv4/tcp_output.c:2547 [inline] tcp_write_xmit+0x641d/0x6bf0 net/ipv4/tcp_output.c:2752 __tcp_push_pending_frames+0x9b/0x360 net/ipv4/tcp_output.c:3015 tcp_push_pending_frames include/net/tcp.h:2107 [inline] tcp_data_snd_check net/ipv4/tcp_input.c:5714 [inline] tcp_rcv_established+0x1026/0x2020 net/ipv4/tcp_input.c:6239 tcp_v4_do_rcv+0x96d/0xc70 net/ipv4/tcp_ipv4.c:1915 sk_backlog_rcv include/net/sock.h:1113 [inline] __release_sock+0x214/0x350 net/core/sock.c:3072 release_sock+0x61/0x1f0 net/core/sock.c:3626 mptcp_push_release net/mptcp/protocol.c:1486 [inline] __mptcp_push_pending+0x6b5/0x9f0 net/mptcp/protocol.c:1625 mptcp_sendmsg+0x10bb/0x1b10 net/mptcp/protocol.c:1903 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x1a6/0x270 net/socket.c:745 ____sys_sendmsg+0x52a/0x7e0 net/socket.c:2603 ___sys_sendmsg net/socket.c:2657 [inline] __sys_sendmsg+0x2aa/0x390 net/socket.c:2686 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fb06e9317f9 Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffe2cfd4f98 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007fb06e97f468 RCX: 00007fb06e9317f9 RDX: 0000000000000000 RSI: 0000000020000080 RDI: 0000000000000005 RBP: 00007fb06e97f446 R08: 0000555500000000 R09: 0000555500000000 R10: 0000555500000000 R11: 0000000000000246 R12: 00007fb06e97f406 R13: 0000000000000001 R14: 00007ffe2cfd4fe0 R15: 0000000000000003 Additionally syzkaller provided a nice reproducer. The repro enables pmtu on the loopback device, leading to tcp_mtu_probe() generating very large probe packets. tcp_can_coalesce_send_queue_head() currently does not check for mptcp-level invariants, and allowed the creation of cross-DSS probes, leading to the mentioned corruption. Address the issue teaching tcp_can_coalesce_send_queue_head() about mptcp using the tcp_skb_can_collapse(), also reducing the code duplication. Fixes: 85712484110d ("tcp: coalesce/collapse must respect MPTCP extensions") Cc: stable@vger.kernel.org Reported-by: syzbot+d1bff73460e33101f0e7@syzkaller.appspotmail.com Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/513 Signed-off-by: Paolo Abeni Acked-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) --- net/ipv4/tcp_output.c | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c index 4fd746bd4d54f621601b20c3821e71370a4a615a..68804fd01dafc48101ca8c3f15991dbe02a0dd6f 100644 --- a/net/ipv4/tcp_output.c +++ b/net/ipv4/tcp_output.c @@ -2342,10 +2342,7 @@ static bool tcp_can_coalesce_send_queue_head(struct sock *sk, int len) if (len <= skb->len) break; - if (unlikely(TCP_SKB_CB(skb)->eor) || - tcp_has_tx_tstamp(skb) || - !skb_pure_zcopy_same(skb, next) || - skb_frags_readable(skb) != skb_frags_readable(next)) + if (tcp_has_tx_tstamp(skb) || !tcp_skb_can_collapse(skb, next)) return false; len -= skb->len; From patchwork Tue Oct 8 11:04:54 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Matthieu Baerts (NGI0)" X-Patchwork-Id: 13826246 X-Patchwork-Delegate: kuba@kernel.org 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 E50EB1DF981; Tue, 8 Oct 2024 11:05:28 +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=1728385529; cv=none; b=bruRK8F8DGa3IEpAqwlERK/gO4vCm232RiXk8YZk+FdqyHAc1mXWgNgP2nLqOTEj6XIhcRwJrnDQC68PU287Vh9qzh9l8g/rtmI5BvPCLErYf3QPl7RPckBa6VQChclmfV87hTCfpMBbxUSBiOMRJEnLSyXrIoOsiDMttCDPaIc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1728385529; c=relaxed/simple; bh=uIa4KGwhFx3LNKZBeUu/lhp2jdewkGAxty3TTR0RmHk=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=Iazzx00wiAIIfQauJ9WOTl58ObGMNTnvPXbXOJV26mVBCJQtkBstwq9hGZGh+w7haDEOmCIYLPHZfMjbRXywC2eukpHeIvsa1+QygbNi0bxigWgC9n2sqyiSKhY96UnRx00lo50p4I8CPnFyym/uvBZwSVVKKPmfcDd+Xytrx6k= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=sWQw+pO8; 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="sWQw+pO8" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A1F1FC4CED1; Tue, 8 Oct 2024 11:05:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1728385528; bh=uIa4KGwhFx3LNKZBeUu/lhp2jdewkGAxty3TTR0RmHk=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=sWQw+pO8EL0POxNsG5NkKZJuS4rW2izDc3/CpLCqiRFlkyLxIoKagxSFx8lv25Pg7 j4DKb06sw/9XZHgqg31QN3rq4VuRtT3eyrdbI9kMQ9LeIvkmxiAGBzBKusv9nxsx0c +W4/lN/xIkrFb5KNUVVDBMWUL5oSXWaaDxaVa5yT+yxf6tCbvZDSKcBrJSw68QTUXP E5ire3vYHh9Z2615qFR3xszURenpLcD6SUwE91UL78Drk+K0ooW48f8chmK0wcMDg2 p9ABRhxHiSp0mKMgWPWotwgdX799qbKaWDbugfw42U328g+IVzCs1zlS5K0CcuZkuj 7oPnVvy4i1UBQ== From: "Matthieu Baerts (NGI0)" Date: Tue, 08 Oct 2024 13:04:54 +0200 Subject: [PATCH net 3/4] mptcp: fallback when MPTCP opts are dropped after 1st data Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Message-Id: <20241008-net-mptcp-fallback-fixes-v1-3-c6fb8e93e551@kernel.org> References: <20241008-net-mptcp-fallback-fixes-v1-0-c6fb8e93e551@kernel.org> In-Reply-To: <20241008-net-mptcp-fallback-fixes-v1-0-c6fb8e93e551@kernel.org> To: mptcp@lists.linux.dev, Mat Martineau , Geliang Tang , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Florian Westphal , David Ahern Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org, "Matthieu Baerts (NGI0)" , stable@vger.kernel.org, Christoph Paasch X-Mailer: b4 0.14.2 X-Developer-Signature: v=1; a=openpgp-sha256; l=3751; i=matttbe@kernel.org; h=from:subject:message-id; bh=uIa4KGwhFx3LNKZBeUu/lhp2jdewkGAxty3TTR0RmHk=; b=owEBbQKS/ZANAwAIAfa3gk9CaaBzAcsmYgBnBRHrX0Pa/sFum93bYCWw25/ScAxBtjfvoCqqe OHxp+q92gWJAjMEAAEIAB0WIQToy4X3aHcFem4n93r2t4JPQmmgcwUCZwUR6wAKCRD2t4JPQmmg c0ZWEAC3csET5nAmzbm4UP5hPl+3hTIzHwP9vcqWBhHodGp8YHe/qz8GdKy4GUDmwECffjg2Xnb OxYyMwvqba7YSpk43/HjJw9Q7pdy6gQv40F8yBWUoAVw1nUF4uL2hOdAS28UAgiUsuJ9xL+ZKWZ hWbPMrubGlIGl+c0ncd1qDzggbmP1hR1XeeRCdqG4e9uMCTmYdXRj1RZ8ONF3UfXhYIfAZjRB7V Yhou+Ttq9NEcOwr8pqJhNbpGsqZuPhhzakfDnLanAZviRspTXQMBfZVc8s8eBKshyx7mZQJv1Z1 KU0yKLPbp+iq/CjSTuvPa91q+YW6zYjrYN6DEQTKHsVUcGVBxYYGfgKnHag/qcnq1LyrX/Czthr nNzE4iWJQAVsBSs1084Z69g8i3K+0gP7dLGTsg6Be6zYBHwmiSlRsk8Jh5X3HzCZCMzvgkT3z4P SRX3v7xlTAwepwafmHf1XxGjTlJZ0JR2t2N/fNzAlVuaboK/8ixgpEd74wLozQeDhcYIRE+Ksrq m9eK5Oh0H8yIFTO62cYTnTv8Cjvz46OE9WKsKpzhTahXqjzb+o3UQqWeXBDWIS59xbSFxqPQe8F cpg4rrl7efbe+BNYNgt8wAh4sRpmEb/ZlYkh6vN9eo3cWo3Bjo6ZG5G0guGnPqzY6uRXCIHoENx 10eA0T9epjnDLmg== X-Developer-Key: i=matttbe@kernel.org; a=openpgp; fpr=E8CB85F76877057A6E27F77AF6B7824F4269A073 X-Patchwork-Delegate: kuba@kernel.org As reported by Christoph [1], before this patch, an MPTCP connection was wrongly reset when a host received a first data packet with MPTCP options after the 3wHS, but got the next ones without. According to the MPTCP v1 specs [2], a fallback should happen in this case, because the host didn't receive a DATA_ACK from the other peer, nor receive data for more than the initial window which implies a DATA_ACK being received by the other peer. The patch here re-uses the same logic as the one used in other places: by looking at allow_infinite_fallback, which is disabled at the creation of an additional subflow. It's not looking at the first DATA_ACK (or implying one received from the other side) as suggested by the RFC, but it is in continuation with what was already done, which is safer, and it fixes the reported issue. The next step, looking at this first DATA_ACK, is tracked in [4]. This patch has been validated using the following Packetdrill script: 0 socket(..., SOCK_STREAM, IPPROTO_MPTCP) = 3 +0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 +0 bind(3, ..., ...) = 0 +0 listen(3, 1) = 0 // 3WHS is OK +0.0 < S 0:0(0) win 65535 +0.0 > S. 0:0(0) ack 1 +0.1 < . 1:1(0) ack 1 win 2048 +0 accept(3, ..., ...) = 4 // Data from the client with valid MPTCP options (no DATA_ACK: normal) +0.1 < P. 1:501(500) ack 1 win 2048 // From here, the MPTCP options will be dropped by a middlebox +0.0 > . 1:1(0) ack 501 +0.1 read(4, ..., 500) = 500 +0 write(4, ..., 100) = 100 // The server replies with data, still thinking MPTCP is being used +0.0 > P. 1:101(100) ack 501 // But the client already did a fallback to TCP, because the two previous packets have been received without MPTCP options +0.1 < . 501:501(0) ack 101 win 2048 +0.0 < P. 501:601(100) ack 101 win 2048 // The server should fallback to TCP, not reset: it didn't get a DATA_ACK, nor data for more than the initial window +0.0 > . 101:101(0) ack 601 Note that this script requires Packetdrill with MPTCP support, see [3]. Fixes: dea2b1ea9c70 ("mptcp: do not reset MP_CAPABLE subflow on mapping errors") Cc: stable@vger.kernel.org Reported-by: Christoph Paasch Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/518 [1] Link: https://datatracker.ietf.org/doc/html/rfc8684#name-fallback [2] Link: https://github.com/multipath-tcp/packetdrill [3] Link: https://github.com/multipath-tcp/mptcp_net-next/issues/519 [4] Reviewed-by: Paolo Abeni Signed-off-by: Matthieu Baerts (NGI0) --- net/mptcp/subflow.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/mptcp/subflow.c b/net/mptcp/subflow.c index e1046a696ab5c79a2cef79870eb79637b432fcd5..25dde81bcb7575958635aaf14a5b8e9a5005e05f 100644 --- a/net/mptcp/subflow.c +++ b/net/mptcp/subflow.c @@ -1282,7 +1282,7 @@ static bool subflow_can_fallback(struct mptcp_subflow_context *subflow) else if (READ_ONCE(msk->csum_enabled)) return !subflow->valid_csum_seen; else - return !subflow->fully_established; + return READ_ONCE(msk->allow_infinite_fallback); } static void mptcp_subflow_fail(struct mptcp_sock *msk, struct sock *ssk) From patchwork Tue Oct 8 11:04:55 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Matthieu Baerts (NGI0)" X-Patchwork-Id: 13826247 X-Patchwork-Delegate: kuba@kernel.org 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 AD0821DFD8E; Tue, 8 Oct 2024 11:05:31 +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=1728385531; cv=none; b=deDm7bSpJD9d16AKB9ZrKclujU+MZNvCQdjKaA4Y8YxfpYTLV/PTkkP4/Ker0gDwlKW35cnPj94QQLryngodYKiI4baROLhTVr2eChDbYpLm660ZsQwRSgeWAj1yMwxGVAmCxMqGLFkm0GBt7046b2xZf2IOPRzT62xySkHVaGQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1728385531; c=relaxed/simple; bh=mSK/tD+BAnWk+pvXOR9WpkVpN2TCVM22yMkgEFX/05I=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=fvXZ6DfvJ207CLKgLCG/eBO84Crm66/NrScvVps2BfHFQaENDLRcnDCGtyotrhjTykI8w1unHRflbB/h5RP8ce1dipm0Ln6WM28e+hRwNj2XoN97W+QWyNvajIINFvqHZu1B/Y+xfaqftC8VkGAQJ3/InaVo6XrX78ME9VeD/pA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=UdLwnxd5; 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="UdLwnxd5" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E73B2C4CECE; Tue, 8 Oct 2024 11:05:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1728385531; bh=mSK/tD+BAnWk+pvXOR9WpkVpN2TCVM22yMkgEFX/05I=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=UdLwnxd5HbfbqZs9ib+ABdPnE5XpM0FH/3sdjQ7yOBMWWGfYIpijzgRers3/bxNAk DNSh3SKqWD88Pc5PgbiZQ/7Upz8dupURTwl+uYhXSZQsvakudwCKI4QknSoTJAjXfq 3FFu3Q82Q1ZBbnay1LX5VJfXUuFwyuLg3BlGRCuqV5Q+moW2VabKsW87FPcNNxPQpz FRFrwYD6T85XwJXrMgTLiZEmDbKvmRChjvlLrKpQrYUkGZXm2uNY2n1kPfZvum6cfE bpTeEBJu1CELwloUmdcGjDQsQXO0eRo9Y6fJnklK5KikiuC3geNCX3y7vhCqVPjtGy JSVH9Q6GWwzbA== From: "Matthieu Baerts (NGI0)" Date: Tue, 08 Oct 2024 13:04:55 +0200 Subject: [PATCH net 4/4] mptcp: pm: do not remove closing subflows Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Message-Id: <20241008-net-mptcp-fallback-fixes-v1-4-c6fb8e93e551@kernel.org> References: <20241008-net-mptcp-fallback-fixes-v1-0-c6fb8e93e551@kernel.org> In-Reply-To: <20241008-net-mptcp-fallback-fixes-v1-0-c6fb8e93e551@kernel.org> To: mptcp@lists.linux.dev, Mat Martineau , Geliang Tang , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Florian Westphal , David Ahern Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org, "Matthieu Baerts (NGI0)" , stable@vger.kernel.org X-Mailer: b4 0.14.2 X-Developer-Signature: v=1; a=openpgp-sha256; l=1419; i=matttbe@kernel.org; h=from:subject:message-id; bh=mSK/tD+BAnWk+pvXOR9WpkVpN2TCVM22yMkgEFX/05I=; b=kA0DAAgB9reCT0JpoHMByyZiAGcFEeugOYizzAHqrnJSwnGJtz2T+QU8eXvkiA7vlv43jcCoR YkCMwQAAQgAHRYhBOjLhfdodwV6bif3eva3gk9CaaBzBQJnBRHrAAoJEPa3gk9CaaBzDhMP/2oV QZoJkvOtQrz7yPCxD3/UPqMMVMY2eZE7QnG9orhqq1qz9yGhlRQrLCw/6B8rclb/IgUUOJGgsdc C0VLDo1kOyWqDrI4YrbUvL/bYos+OiE+9fuungdpe7oADdv1jIWEL09sHA8qef4H49QbMIlihsI RH5XMAZ/vUAvvMjPTFxoHvRoC51jmWi/1qr2ToQ1lqMS+z5sk8ftO/W16jfvfJlCxGCY6tg4ze1 WD4qIGLLmVmqIrAtzFc54gmbJameCeDBq/6oN8HFXhvvw3ckx7Jvi1wAJjLowegWTPyBN9JrmiX 0JOz+oymvau6EW/4MFQ9jOpArulPk4zYH/M06WN+O1H1HpLA2DKH4ricDFoHoMX9cHFJ9omZUTs X6KZc4T6rEcCw4cFJfGsnNnynZgkLn7WCZBeenrZOR8eM8Bfb/dQxsxhHbPl8TzgXjue6jNB50i r4Q4qyFnfm6xk60XhbKorCoKB9lBzui8aJJFKTG72UgJ8HIssS+MTUzvUzL1+vB/SiZa4lBMpzS Sxbx8fd316b1KJ2ehuZAuaotHkAJ380cWqv6PL7Bz4JA5O2kbjkDw9gq6YtSWFBgKPQ6OgiGJ6e gFeEJjC6qkDwPfhLJaSZe7ogv7I3pLCE9U47qlsUR41j8vw64HzrYKbde4vC5M6WendorsjbirH BB4rY X-Developer-Key: i=matttbe@kernel.org; a=openpgp; fpr=E8CB85F76877057A6E27F77AF6B7824F4269A073 X-Patchwork-Delegate: kuba@kernel.org In a previous fix, the in-kernel path-manager has been modified not to retrigger the removal of a subflow if it was already closed, e.g. when the initial subflow is removed, but kept in the subflows list. To be complete, this fix should also skip the subflows that are in any closing state: mptcp_close_ssk() will initiate the closure, but the switch to the TCP_CLOSE state depends on the other peer. Fixes: 58e1b66b4e4b ("mptcp: pm: do not remove already closed subflows") Cc: stable@vger.kernel.org Suggested-by: Paolo Abeni Acked-by: Paolo Abeni Signed-off-by: Matthieu Baerts (NGI0) --- net/mptcp/pm_netlink.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/net/mptcp/pm_netlink.c b/net/mptcp/pm_netlink.c index 64fe0e7d87d7323583ef9ee5909c833a78e727c2..f6f0a38a0750f82bc909f02a75beec980d951f1f 100644 --- a/net/mptcp/pm_netlink.c +++ b/net/mptcp/pm_netlink.c @@ -860,7 +860,8 @@ static void mptcp_pm_nl_rm_addr_or_subflow(struct mptcp_sock *msk, int how = RCV_SHUTDOWN | SEND_SHUTDOWN; u8 id = subflow_get_local_id(subflow); - if (inet_sk_state_load(ssk) == TCP_CLOSE) + if ((1 << inet_sk_state_load(ssk)) & + (TCPF_FIN_WAIT1 | TCPF_FIN_WAIT2 | TCPF_CLOSING | TCPF_CLOSE)) continue; if (rm_type == MPTCP_MIB_RMADDR && remote_id != rm_id) continue;