--- /dev/null
+From stable+bounces-52669-greg=kroah.com@vger.kernel.org Tue Jun 18 14:25:14 2024
+From: "Matthieu Baerts (NGI0)" <matttbe@kernel.org>
+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 <mptcp@lists.linux.dev>, Paolo Abeni <pabeni@redhat.com>, Mat Martineau <martineau@kernel.org>, Christoph Paasch <cpaasch@apple.com>, Matthieu Baerts <matttbe@kernel.org>, Jakub Kicinski <kuba@kernel.org>
+Message-ID: <20240618122444.640369-2-matttbe@kernel.org>
+
+From: Paolo Abeni <pabeni@redhat.com>
+
+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 <martineau@kernel.org>
+Fixes: 8fd738049ac3 ("mptcp: fallback in case of simultaneous connect")
+Cc: stable@vger.kernel.org
+Reported-by: Christoph Paasch <cpaasch@apple.com>
+Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/485
+Signed-off-by: Paolo Abeni <pabeni@redhat.com>
+Reviewed-by: Mat Martineau <martineau@kernel.org>
+Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
+Link: https://lore.kernel.org/r/20240607-upstream-net-20240607-misc-fixes-v1-1-1ab9ddfa3d00@kernel.org
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+[ 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) <matttbe@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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);
--- /dev/null
+From stable+bounces-52670-greg=kroah.com@vger.kernel.org Tue Jun 18 14:25:24 2024
+From: "Matthieu Baerts (NGI0)" <matttbe@kernel.org>
+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 <mptcp@lists.linux.dev>, YonglongLi <liyonglong@chinatelecom.cn>, Matthieu Baerts <matttbe@kernel.org>, Jakub Kicinski <kuba@kernel.org>
+Message-ID: <20240618122511.640963-2-matttbe@kernel.org>
+
+From: YonglongLi <liyonglong@chinatelecom.cn>
+
+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) <matttbe@kernel.org>
+Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
+Signed-off-by: YonglongLi <liyonglong@chinatelecom.cn>
+Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
+Link: https://lore.kernel.org/r/20240607-upstream-net-20240607-misc-fixes-v1-2-1ab9ddfa3d00@kernel.org
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+[ 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) <matttbe@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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)
--- /dev/null
+From stable+bounces-52671-greg=kroah.com@vger.kernel.org Tue Jun 18 14:25:44 2024
+From: "Matthieu Baerts (NGI0)" <matttbe@kernel.org>
+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 <mptcp@lists.linux.dev>, YonglongLi <liyonglong@chinatelecom.cn>, Matthieu Baerts <matttbe@kernel.org>, Mat Martineau <martineau@kernel.org>, Jakub Kicinski <kuba@kernel.org>
+Message-ID: <20240618122531.641433-2-matttbe@kernel.org>
+
+From: YonglongLi <liyonglong@chinatelecom.cn>
+
+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) <matttbe@kernel.org>
+Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
+Signed-off-by: YonglongLi <liyonglong@chinatelecom.cn>
+Reviewed-by: Mat Martineau <martineau@kernel.org>
+Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
+Link: https://lore.kernel.org/r/20240607-upstream-net-20240607-misc-fixes-v1-3-1ab9ddfa3d00@kernel.org
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+[ 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) <matttbe@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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);
+ }
+
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
projects / thirdparty / kernel / stable-queue.git / commitdiff
