From 9cf6c3b8b44a9e2c7cc7f38c2ed2d836ed79fb5a Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Wed, 19 Jun 2024 12:41:02 +0200 Subject: [PATCH] 5.10-stable patches added patches: mptcp-ensure-snd_una-is-properly-initialized-on-connect.patch mptcp-pm-inc-rmaddr-mib-counter-once-per-rm_addr-id.patch mptcp-pm-update-add_addr-counters-after-connect.patch --- ...a-is-properly-initialized-on-connect.patch | 50 ++++++++++ ...addr-mib-counter-once-per-rm_addr-id.patch | 64 ++++++++++++ ...date-add_addr-counters-after-connect.patch | 98 +++++++++++++++++++ queue-5.10/series | 3 + 4 files changed, 215 insertions(+) create mode 100644 queue-5.10/mptcp-ensure-snd_una-is-properly-initialized-on-connect.patch create mode 100644 queue-5.10/mptcp-pm-inc-rmaddr-mib-counter-once-per-rm_addr-id.patch create mode 100644 queue-5.10/mptcp-pm-update-add_addr-counters-after-connect.patch diff --git a/queue-5.10/mptcp-ensure-snd_una-is-properly-initialized-on-connect.patch b/queue-5.10/mptcp-ensure-snd_una-is-properly-initialized-on-connect.patch new file mode 100644 index 00000000000..5451faafe5f --- /dev/null +++ b/queue-5.10/mptcp-ensure-snd_una-is-properly-initialized-on-connect.patch @@ -0,0 +1,50 @@ +From stable+bounces-52669-greg=kroah.com@vger.kernel.org Tue Jun 18 14:25:14 2024 +From: "Matthieu Baerts (NGI0)" +Date: Tue, 18 Jun 2024 14:24:45 +0200 +Subject: mptcp: ensure snd_una is properly initialized on connect +To: stable@vger.kernel.org, gregkh@linuxfoundation.org +Cc: MPTCP Upstream , Paolo Abeni , Mat Martineau , Christoph Paasch , Matthieu Baerts , Jakub Kicinski +Message-ID: <20240618122444.640369-2-matttbe@kernel.org> + +From: Paolo Abeni + +commit 8031b58c3a9b1db3ef68b3bd749fbee2e1e1aaa3 upstream. + +This is strictly related to commit fb7a0d334894 ("mptcp: ensure snd_nxt +is properly initialized on connect"). It turns out that syzkaller can +trigger the retransmit after fallback and before processing any other +incoming packet - so that snd_una is still left uninitialized. + +Address the issue explicitly initializing snd_una together with snd_nxt +and write_seq. + +Suggested-by: Mat Martineau +Fixes: 8fd738049ac3 ("mptcp: fallback in case of simultaneous connect") +Cc: stable@vger.kernel.org +Reported-by: Christoph Paasch +Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/485 +Signed-off-by: Paolo Abeni +Reviewed-by: Mat Martineau +Signed-off-by: Matthieu Baerts (NGI0) +Link: https://lore.kernel.org/r/20240607-upstream-net-20240607-misc-fixes-v1-1-1ab9ddfa3d00@kernel.org +Signed-off-by: Jakub Kicinski +[ Conflicts in protocol.c, similar to the ones from commit 99951b62bf20 + ("mptcp: ensure snd_nxt is properly initialized on connect"), with the + same resolution. Note that in this version, 'snd_una' is an atomic64 + type, so use atomic64_set() instead, as it is done everywhere else. ] +Signed-off-by: Matthieu Baerts (NGI0) +Signed-off-by: Greg Kroah-Hartman +--- + net/mptcp/protocol.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/net/mptcp/protocol.c ++++ b/net/mptcp/protocol.c +@@ -2646,6 +2646,7 @@ static int mptcp_stream_connect(struct s + mptcp_subflow_early_fallback(msk, subflow); + + WRITE_ONCE(msk->write_seq, subflow->idsn); ++ atomic64_set(&msk->snd_una, msk->write_seq); + + do_connect: + err = ssock->ops->connect(ssock, uaddr, addr_len, flags); diff --git a/queue-5.10/mptcp-pm-inc-rmaddr-mib-counter-once-per-rm_addr-id.patch b/queue-5.10/mptcp-pm-inc-rmaddr-mib-counter-once-per-rm_addr-id.patch new file mode 100644 index 00000000000..816d5703b1d --- /dev/null +++ b/queue-5.10/mptcp-pm-inc-rmaddr-mib-counter-once-per-rm_addr-id.patch @@ -0,0 +1,64 @@ +From stable+bounces-52670-greg=kroah.com@vger.kernel.org Tue Jun 18 14:25:24 2024 +From: "Matthieu Baerts (NGI0)" +Date: Tue, 18 Jun 2024 14:25:12 +0200 +Subject: mptcp: pm: inc RmAddr MIB counter once per RM_ADDR ID +To: stable@vger.kernel.org, gregkh@linuxfoundation.org +Cc: MPTCP Upstream , YonglongLi , Matthieu Baerts , Jakub Kicinski +Message-ID: <20240618122511.640963-2-matttbe@kernel.org> + +From: YonglongLi + +commit 6a09788c1a66e3d8b04b3b3e7618cc817bb60ae9 upstream. + +The RmAddr MIB counter is supposed to be incremented once when a valid +RM_ADDR has been received. Before this patch, it could have been +incremented as many times as the number of subflows connected to the +linked address ID, so it could have been 0, 1 or more than 1. + +The "RmSubflow" is incremented after a local operation. In this case, +it is normal to tied it with the number of subflows that have been +actually removed. + +The "remove invalid addresses" MP Join subtest has been modified to +validate this case. A broadcast IP address is now used instead: the +client will not be able to create a subflow to this address. The +consequence is that when receiving the RM_ADDR with the ID attached to +this broadcast IP address, no subflow linked to this ID will be found. + +Fixes: 7a7e52e38a40 ("mptcp: add RM_ADDR related mibs") +Cc: stable@vger.kernel.org +Co-developed-by: Matthieu Baerts (NGI0) +Signed-off-by: Matthieu Baerts (NGI0) +Signed-off-by: YonglongLi +Signed-off-by: Matthieu Baerts (NGI0) +Link: https://lore.kernel.org/r/20240607-upstream-net-20240607-misc-fixes-v1-2-1ab9ddfa3d00@kernel.org +Signed-off-by: Jakub Kicinski +[ Conflicts in pm_netlink.c because the commit 9f12e97bf16c ("mptcp: + unify RM_ADDR and RM_SUBFLOW receiving"), and commit d0b698ca9a27 + ("mptcp: remove multi addresses in PM") are not in this version. To + fix the issue, the incrementation should be done outside the loop: the + same resolution has been applied here. + The selftest modification has been dropped, because the modified test + is not in this version. That's fine, we can test with selftests from a + newer version. ] +Signed-off-by: Matthieu Baerts (NGI0) +Signed-off-by: Greg Kroah-Hartman +--- + net/mptcp/pm_netlink.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/net/mptcp/pm_netlink.c ++++ b/net/mptcp/pm_netlink.c +@@ -427,10 +427,10 @@ void mptcp_pm_nl_rm_addr_received(struct + msk->pm.subflows--; + WRITE_ONCE(msk->pm.accept_addr, true); + +- __MPTCP_INC_STATS(sock_net(sk), MPTCP_MIB_RMADDR); +- + break; + } ++ ++ __MPTCP_INC_STATS(sock_net(sk), MPTCP_MIB_RMADDR); + } + + void mptcp_pm_nl_rm_subflow_received(struct mptcp_sock *msk, u8 rm_id) diff --git a/queue-5.10/mptcp-pm-update-add_addr-counters-after-connect.patch b/queue-5.10/mptcp-pm-update-add_addr-counters-after-connect.patch new file mode 100644 index 00000000000..56acd059b65 --- /dev/null +++ b/queue-5.10/mptcp-pm-update-add_addr-counters-after-connect.patch @@ -0,0 +1,98 @@ +From stable+bounces-52671-greg=kroah.com@vger.kernel.org Tue Jun 18 14:25:44 2024 +From: "Matthieu Baerts (NGI0)" +Date: Tue, 18 Jun 2024 14:25:32 +0200 +Subject: mptcp: pm: update add_addr counters after connect +To: stable@vger.kernel.org, gregkh@linuxfoundation.org +Cc: MPTCP Upstream , YonglongLi , Matthieu Baerts , Mat Martineau , Jakub Kicinski +Message-ID: <20240618122531.641433-2-matttbe@kernel.org> + +From: YonglongLi + +commit 40eec1795cc27b076d49236649a29507c7ed8c2d upstream. + +The creation of new subflows can fail for different reasons. If no +subflow have been created using the received ADD_ADDR, the related +counters should not be updated, otherwise they will never be decremented +for events related to this ID later on. + +For the moment, the number of accepted ADD_ADDR is only decremented upon +the reception of a related RM_ADDR, and only if the remote address ID is +currently being used by at least one subflow. In other words, if no +subflow can be created with the received address, the counter will not +be decremented. In this case, it is then important not to increment +pm.add_addr_accepted counter, and not to modify pm.accept_addr bit. + +Note that this patch does not modify the behaviour in case of failures +later on, e.g. if the MP Join is dropped or rejected. + +The "remove invalid addresses" MP Join subtest has been modified to +validate this case. The broadcast IP address is added before the "valid" +address that will be used to successfully create a subflow, and the +limit is decreased by one: without this patch, it was not possible to +create the last subflow, because: + +- the broadcast address would have been accepted even if it was not + usable: the creation of a subflow to this address results in an error, + +- the limit of 2 accepted ADD_ADDR would have then been reached. + +Fixes: 01cacb00b35c ("mptcp: add netlink-based PM") +Cc: stable@vger.kernel.org +Co-developed-by: Matthieu Baerts (NGI0) +Signed-off-by: Matthieu Baerts (NGI0) +Signed-off-by: YonglongLi +Reviewed-by: Mat Martineau +Signed-off-by: Matthieu Baerts (NGI0) +Link: https://lore.kernel.org/r/20240607-upstream-net-20240607-misc-fixes-v1-3-1ab9ddfa3d00@kernel.org +Signed-off-by: Jakub Kicinski +[ Conflicts in pm_netlink.c because commit 1a0d6136c5f0 ("mptcp: local + addresses fullmesh") is not present in this version (+ others changing + the context). To resolve the conflicts, the same block is moved later, + and under the condition that the call to __mptcp_subflow_connect() + didn't fail. + The selftest modification has been dropped, because the modified test + is not in this version. That's fine, we can test with selftests from a + newer version. ] +Signed-off-by: Matthieu Baerts (NGI0) +Signed-off-by: Greg Kroah-Hartman +--- + net/mptcp/pm_netlink.c | 14 +++++++++----- + 1 file changed, 9 insertions(+), 5 deletions(-) + +--- a/net/mptcp/pm_netlink.c ++++ b/net/mptcp/pm_netlink.c +@@ -371,15 +371,12 @@ void mptcp_pm_nl_add_addr_received(struc + struct sock *sk = (struct sock *)msk; + struct mptcp_addr_info remote; + struct mptcp_addr_info local; ++ int err; + + pr_debug("accepted %d:%d remote family %d", + msk->pm.add_addr_accepted, msk->pm.add_addr_accept_max, + msk->pm.remote.family); +- msk->pm.add_addr_accepted++; + msk->pm.subflows++; +- if (msk->pm.add_addr_accepted >= msk->pm.add_addr_accept_max || +- msk->pm.subflows >= msk->pm.subflows_max) +- WRITE_ONCE(msk->pm.accept_addr, false); + + /* connect to the specified remote address, using whatever + * local address the routing configuration will pick. +@@ -391,9 +388,16 @@ void mptcp_pm_nl_add_addr_received(struc + local.family = remote.family; + + spin_unlock_bh(&msk->pm.lock); +- __mptcp_subflow_connect((struct sock *)msk, &local, &remote); ++ err = __mptcp_subflow_connect((struct sock *)msk, &local, &remote); + spin_lock_bh(&msk->pm.lock); + ++ if (!err) { ++ msk->pm.add_addr_accepted++; ++ if (msk->pm.add_addr_accepted >= msk->pm.add_addr_accept_max || ++ msk->pm.subflows >= msk->pm.subflows_max) ++ WRITE_ONCE(msk->pm.accept_addr, false); ++ } ++ + mptcp_pm_announce_addr(msk, &remote, true); + } + diff --git a/queue-5.10/series b/queue-5.10/series index 0c07199552e..c2cd366bdff 100644 --- a/queue-5.10/series +++ b/queue-5.10/series @@ -125,3 +125,6 @@ nilfs2-fix-potential-kernel-bug-due-to-lack-of-writeback-flag-waiting.patch tick-nohz_full-don-t-abuse-smp_call_function_single-in-tick_setup_device.patch serial-8250_pxa-configure-tx_loadsz-to-match-fifo-irq-level.patch hugetlb_encode.h-fix-undefined-behaviour-34-26.patch +mptcp-ensure-snd_una-is-properly-initialized-on-connect.patch +mptcp-pm-inc-rmaddr-mib-counter-once-per-rm_addr-id.patch +mptcp-pm-update-add_addr-counters-after-connect.patch -- 2.47.3