From nobody Wed Dec 4 19:04:01 2024 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 6A8853224; Sun, 8 Sep 2024 13:06:52 +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=1725800812; cv=none; b=KlhcnO5NZJfa+Ca0a+keLEpqWkd1ilktf+mw54hggUNB/pHGPQm3eBLxcck9KV6vAtYwp9IjKETRkIud7PINH3Urwd8lH4eon5S50J2LkxemVGU7sOjiGPm6s6kOfQIaoEFRm6DzhyXcfZGwBER4Kr1Y7D4AtqN8wdvUxrcXLCo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1725800812; c=relaxed/simple; bh=lvQF/HmEdHBotU0EASU25aLKmwf4FAMeKeYyH9CWdDA=; h=Subject:To:Cc:From:Date:In-Reply-To:Message-ID:MIME-Version: Content-Type; b=UQsCqLQQw/UKUqVm6fBRDvSpzZqKUJvtqMaS8nEZ/WqrzBn5vyQy6io7v+d5k9k2Pd6sZCk604QBinZ3r30aNBIKoWuHN6iIpxaDtAXrF+5YZJ/iF+NFXWf59DysjaMuMHABaifkM0Ue7rRxFAjZ5EnEqSW8uphkMbBBNFrbri8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=Uvnk1tDr; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="Uvnk1tDr" Received: by smtp.kernel.org (Postfix) with ESMTPSA id DBD0BC4CEC3; Sun, 8 Sep 2024 13:06:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1725800812; bh=lvQF/HmEdHBotU0EASU25aLKmwf4FAMeKeYyH9CWdDA=; h=Subject:To:Cc:From:Date:In-Reply-To:From; b=Uvnk1tDrcpi9sNJOLQjD0if7gCzmJms6OREbk9Um3frKALbgDXcTJ/0zH770ewlfU xUr6iHqu3qSscZ9CEF7KR5bf8QiG3zp9m7EuPVUBVhx243MZnrxWkUqeWWs6g7cVM7 /vRfUmFo0FRY1gwIPjZb1I3kavReaAMsFVQ7Uw0w= Subject: Patch "mptcp: pm: ADD_ADDR 0 is not a new address" has been added to the 5.15-stable tree To: gregkh@linuxfoundation.org,martineau@kernel.org,matttbe@kernel.org,mptcp@lists.linux.dev,pabeni@redhat.com Cc: From: Date: Sun, 08 Sep 2024 15:06:43 +0200 In-Reply-To: <20240906083454.1772761-2-matttbe@kernel.org> Message-ID: <2024090843-basket-machine-6eda@gregkh> Precedence: bulk X-Mailing-List: mptcp@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-stable: commit X-Patchwork-Hint: ignore Content-Type: text/plain; charset="utf-8" This is a note to let you know that I've just added the patch titled mptcp: pm: ADD_ADDR 0 is not a new address to the 5.15-stable tree which can be found at: http://www.kernel.org/git/?p=3Dlinux/kernel/git/stable/stable-queue.git= ;a=3Dsummary The filename of the patch is: mptcp-pm-add_addr-0-is-not-a-new-address.patch and it can be found in the queue-5.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let know about it. From stable+bounces-73741-greg=3Dkroah.com@vger.kernel.org Fri Sep 6 10:35= :13 2024 From: "Matthieu Baerts (NGI0)" Date: Fri, 6 Sep 2024 10:34:55 +0200 Subject: mptcp: pm: ADD_ADDR 0 is not a new address To: stable@vger.kernel.org, gregkh@linuxfoundation.org Cc: MPTCP Upstream , "Matthieu Baerts (NGI0)" , Mat Martineau , Paolo Abeni Message-ID: <20240906083454.1772761-2-matttbe@kernel.org> From: "Matthieu Baerts (NGI0)" commit 57f86203b41c98b322119dfdbb1ec54ce5e3369b upstream. The ADD_ADDR 0 with the address from the initial subflow should not be considered as a new address: this is not something new. If the host receives it, it simply means that the address is available again. When receiving an ADD_ADDR for the ID 0, the PM already doesn't consider it as new by not incrementing the 'add_addr_accepted' counter. But the 'accept_addr' might not be set if the limit has already been reached: this can be bypassed in this case. But before, it is important to check that this ADD_ADDR for the ID 0 is for the same address as the initial subflow. If not, it is not something that should happen, and the ADD_ADDR can be ignored. Note that if an ADD_ADDR is received while there is already a subflow opened using the same address, this ADD_ADDR is ignored as well. It means that if multiple ADD_ADDR for ID 0 are received, there will not be any duplicated subflows created by the client. Fixes: d0876b2284cf ("mptcp: add the incoming RM_ADDR support") Cc: stable@vger.kernel.org Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts (NGI0) Signed-off-by: Paolo Abeni [ Conflicts in pm.c, due to commit 4d25247d3ae4 ("mptcp: bypass in-kernel PM restrictions for non-kernel PMs"), which is not in this version, and changes the context. The same fix can be applied here by adding the new check at the same place. Note that addresses_equal() has been used instead of mptcp_addresses_equal(), renamed in commit 4638de5aefe5 ("mptcp: handle local addrs announced by userspace PMs"), not in this version. ] Signed-off-by: Matthieu Baerts (NGI0) Signed-off-by: Greg Kroah-Hartman --- net/mptcp/pm.c | 4 +++- net/mptcp/pm_netlink.c | 9 +++++++++ net/mptcp/protocol.h | 2 ++ 3 files changed, 14 insertions(+), 1 deletion(-) --- a/net/mptcp/pm.c +++ b/net/mptcp/pm.c @@ -189,7 +189,9 @@ void mptcp_pm_add_addr_received(struct m =20 spin_lock_bh(&pm->lock); =20 - if (!READ_ONCE(pm->accept_addr)) { + /* id0 should not have a different address */ + if ((addr->id =3D=3D 0 && !mptcp_pm_nl_is_init_remote_addr(msk, addr)) || + (addr->id > 0 && !READ_ONCE(pm->accept_addr))) { mptcp_pm_announce_addr(msk, addr, true); mptcp_pm_add_addr_send_ack(msk); } else if (mptcp_pm_schedule_work(msk, MPTCP_PM_ADD_ADDR_RECEIVED)) { --- a/net/mptcp/pm_netlink.c +++ b/net/mptcp/pm_netlink.c @@ -669,6 +669,15 @@ add_addr_echo: mptcp_pm_nl_addr_send_ack(msk); } =20 +bool mptcp_pm_nl_is_init_remote_addr(struct mptcp_sock *msk, + const struct mptcp_addr_info *remote) +{ + struct mptcp_addr_info mpc_remote; + + remote_address((struct sock_common *)msk, &mpc_remote); + return addresses_equal(&mpc_remote, remote, remote->port); +} + void mptcp_pm_nl_addr_send_ack(struct mptcp_sock *msk) { struct mptcp_subflow_context *subflow; --- a/net/mptcp/protocol.h +++ b/net/mptcp/protocol.h @@ -742,6 +742,8 @@ void mptcp_pm_add_addr_received(struct m void mptcp_pm_add_addr_echoed(struct mptcp_sock *msk, const struct mptcp_addr_info *addr); void mptcp_pm_add_addr_send_ack(struct mptcp_sock *msk); +bool mptcp_pm_nl_is_init_remote_addr(struct mptcp_sock *msk, + const struct mptcp_addr_info *remote); void mptcp_pm_nl_addr_send_ack(struct mptcp_sock *msk); void mptcp_pm_rm_addr_received(struct mptcp_sock *msk, const struct mptcp_rm_list *rm_list); Patches currently in stable-queue which might be from matttbe@kernel.org are queue-5.15/mptcp-pm-avoid-possible-uaf-when-selecting-endp.patch queue-5.15/mptcp-pm-only-decrement-add_addr_accepted-for-mpj-req.patch queue-5.15/mptcp-pm-fullmesh-select-the-right-id-later.patch queue-5.15/mptcp-pm-skip-connecting-to-already-established-sf.patch queue-5.15/mptcp-pm-re-using-id-of-unused-flushed-subflows.patch queue-5.15/mptcp-pm-add_addr-0-is-not-a-new-address.patch queue-5.15/mptcp-constify-a-bunch-of-of-helpers.patch queue-5.15/mptcp-pm-do-not-remove-already-closed-subflows.patch queue-5.15/mptcp-pr_debug-add-missing-n-at-the-end.patch queue-5.15/mptcp-pm-check-add_addr_accept_max-before-accepting-new-add_addr= .patch queue-5.15/mptcp-close-subflow-when-receiving-tcp-fin.patch queue-5.15/mptcp-avoid-duplicated-sub_closed-events.patch queue-5.15/mptcp-pm-send-ack-on-an-active-subflow.patch