From nobody Sat Jul 25 07:28:25 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 E0CAC43E071; Tue, 21 Jul 2026 22:15:08 +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=1784672109; cv=none; b=WQw8YywaTI4jLxYfWMPR+BX0gbX4eAIUBBM+ohXNmCVNGMkwob6C4ZAydsWB6MtBGTjhYOJ47amRmfXpzM4DoBm++ADNo1Wz3Z0rxmll1hRVXhnIrEXsxNOZRGbbTgRDTXwMKoTk4Pkyhzn/CwU5UWk+/Ws2FMXEYO9NuYbmmHg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784672109; c=relaxed/simple; bh=0qURqO9kn/zcU54YmnorJujhtp0lYSnY10DK+OWj0sk=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=qSIgoPGS1ZhNlvNZeQCvuAlX/yYyap76CQ77khFqxbakdoVuBHIgxEYvDA1FEEf/HHzxCZzl80x0XsAZ3cbzfkd7InsChaBLpEFI3VZ0D4SYq7Ct4NYvVRSwWL+a1ncx7XOG2waTX3Lbxc2dfqAdcMsptwTNZCXRAec6LPx5oLU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=A2evbRv2; 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="A2evbRv2" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 939C51F000E9; Tue, 21 Jul 2026 22:15:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1784672108; bh=FHRp21V3fuZAYhHcKdmzGkJ92F9rNGdh3mSVIi9BnDw=; h=From:Date:Subject:References:In-Reply-To:To:Cc; b=A2evbRv2qugeZHRl40FBwW5CbsopYJEt8Gyi5jADqTwvnKAejf0J/kOYlKp2zYTu7 Q4NOknpc2cp597N4JFV5lWcdkaj6yH7dCvFRfJTmZ19O2g7mDqCus4eiFqtr5wZRyY myK51G5W0ebG8CG0uESmzcYpO2MzWp5pGdT4eNXmYpa7J7gqSekUPZ96cnvwKNDBZS xUcij9khnoMF7N3TKm+A3sW2bStqDHNf5T2Y5zo8grAbHwT/lSnpWfDdJUtPIv/BlH LEshIhpzIJOyCFEn4Fp3ctmN2a6JW08+g/kVOadncEP5rzkzK1B739GbYGg3JZIfpM Wn9iTCcmOMoKw== From: "Matthieu Baerts (NGI0)" Date: Wed, 22 Jul 2026 00:14:38 +0200 Subject: [PATCH net 1/5] mptcp: decrement subflows counter on failed passive join Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20260722-net-mptcp-misc-fixes-7-2-rc5-v1-1-6fb595bc86ef@kernel.org> References: <20260722-net-mptcp-misc-fixes-7-2-rc5-v1-0-6fb595bc86ef@kernel.org> In-Reply-To: <20260722-net-mptcp-misc-fixes-7-2-rc5-v1-0-6fb595bc86ef@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)" , Chenguang Zhao , stable@vger.kernel.org X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openpgp-sha256; l=1082; i=matttbe@kernel.org; h=from:subject:message-id; bh=gXFS1yu5DdyRn+H8JzWtKZhQG8QH+B/3J0IBrtKs4tk=; b=owGbwMvMwCVWo/Th0Gd3rumMp9WSGLLi3yenrGbg0436yDotyc+uKeE/p6G8janlq7NWFWWf/ 3C68v/vKGVhEONikBVTZJFui8yf+byKt8TLzwJmDisTyBAGLk4BmIiwM8NvVqvHQXdb1Fn9dqV9 9cqLqGr9KruxKuen3vPj61U2ff1uz/Df9aSiYnjb12Va4V8sTK9vmlZbu4pv58uJ+7JNfJNnMN9 kBgA= X-Developer-Key: i=matttbe@kernel.org; a=openpgp; fpr=E8CB85F76877057A6E27F77AF6B7824F4269A073 From: Chenguang Zhao mptcp_pm_allow_new_subflow() increments extra_subflows before __mptcp_finish_join() on the passive MP_JOIN path. In case of race conditions, the subflow is dropped without calling mptcp_close_ssk(), so the counter is not rolled back. Call mptcp_pm_close_subflow() when the join completion fails to decrement the subflows counter. Fixes: 10f6d46c943d ("mptcp: fix race between MP_JOIN and close") Cc: stable@vger.kernel.org Signed-off-by: Chenguang Zhao Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) --- net/mptcp/protocol.c | 1 + 1 file changed, 1 insertion(+) diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c index cb9515f505aa..b32f0cd262a7 100644 --- a/net/mptcp/protocol.c +++ b/net/mptcp/protocol.c @@ -3907,6 +3907,7 @@ bool mptcp_finish_join(struct sock *ssk) mptcp_data_unlock(parent); =20 if (!ret) { + mptcp_pm_close_subflow(msk); err_prohibited: subflow->reset_reason =3D MPTCP_RST_EPROHIBIT; return false; --=20 2.53.0 From nobody Sat Jul 25 07:28:25 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 6AC0643F8C9; Tue, 21 Jul 2026 22:15:11 +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=1784672112; cv=none; b=Kth1Z+gIeOV3/fx6kQLVNzV+htOZqPmLpPkNNaCymSALgtBuYMa7OIDD4RLabEEkznlW2Vu3gUFN8n/Cm44RWJSc+SpVzVaPuz0n0RXLF+n7ZtWK8aXMzzY4P8rEyCpuW1KMHXxwvPOE8X6p7OEx68OFg2jXR0/dJzhFITXDfqY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784672112; c=relaxed/simple; bh=ZtaW8oB5hy7mvoPP6JzZWBB7H//QrhxnvarhkX8e+Gw=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=ffmu56Tk5e632Nv/2IaOcedtCJtFNfYtwKKpVIRppvaCuU/OhmIOAXANzVCA5daQ9662M3wCidV0XqQEAorzrvryPjuPxKGWkmETXmm99Kyw8XcvXMW+oO5RFhamo2CvrstjdrKzinhHJ4u/w6xHcI4HqeF3hlzsT0CIzvAUhYg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=k/jIsuIm; 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="k/jIsuIm" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1C9CA1F00A3D; Tue, 21 Jul 2026 22:15:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1784672111; bh=CMinFyqr5njRocBeZqP8BIJeE385Om6zUZZvJdLn7Ns=; h=From:Date:Subject:References:In-Reply-To:To:Cc; b=k/jIsuImzJNPitK2Pwg2zK45BxZ568L2PwSSRa85MJiRmPdDOZQDiHwZMOcLoXQ3v 6412Saz4X6Phcz++YT8h6R8lXXiMBu2QXlMMYHShmsVluLTYuyat9cqMsKUwjUOlAe haVLfbUBhvOKmo4pdIb4gALMHWEADhc9SjgY24qV/1+eKoVQGm9B84+SGYyFFTZ41i LqB/BGvWCnZSk+8Jl/rU07wvwo1V919f5u9bl3IXokB8pyu8SnAPhAeIs5PgYBdsFf K5BFKtwvF9vkXMtpblhfUDheOoy0OxfaKYbsyox7v0LS14ZC0PI71J0ShiWPKTYdrn 3vARhF8QjJeWQ== From: "Matthieu Baerts (NGI0)" Date: Wed, 22 Jul 2026 00:14:39 +0200 Subject: [PATCH net 2/5] mptcp: pm: userspace: fix use-after-free in get_local_id Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20260722-net-mptcp-misc-fixes-7-2-rc5-v1-2-6fb595bc86ef@kernel.org> References: <20260722-net-mptcp-misc-fixes-7-2-rc5-v1-0-6fb595bc86ef@kernel.org> In-Reply-To: <20260722-net-mptcp-misc-fixes-7-2-rc5-v1-0-6fb595bc86ef@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, Xuanqiang Luo , Geliang Tang X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openpgp-sha256; l=3322; i=matttbe@kernel.org; h=from:subject:message-id; bh=8DCHTVbUXEUEAILN1E701JGgPjN3FeF+obur5MPG3d8=; b=owGbwMvMwCVWo/Th0Gd3rumMp9WSGLLi36coqCntjvt3U3L1Of5ZThJHXghrPeSWTJ/o9GmV8 H2V0vbojlIWBjEuBlkxRRbptsj8mc+reEu8/Cxg5rAygQxh4OIUgJv8kJHhkelupuXsB+t2GfdY 78tRcbj91Vnq6Pn0cOunR8/f0zpSzsjwxris9bSH8Z8V2aYP7n2amHFbZppGYH+fGHOVVGOqrAw zAA== X-Developer-Key: i=matttbe@kernel.org; a=openpgp; fpr=E8CB85F76877057A6E27F77AF6B7824F4269A073 From: Geliang Tang In mptcp_pm_userspace_get_local_id(), the address entry is looked up under spinlock, but its id is read after dropping the lock. A concurrent deletion can free the entry between the unlock and the read, leading to UAF. The race window is narrow. It was reproduced only with a locally constructed stress test that repeatedly overlaps an MP_JOIN SYN with a MPTCP_PM_CMD_SUBFLOW_DESTROY request. However, the KASAN report below confirms that the race is reachable: [ 666.319376] BUG: KASAN: slab-use-after-free in mptcp_userspace_pm_get_= local_id+0x1dc/0x1f0 [ 666.319386] Read of size 1 at addr ffff888124845610 by task swapper/0/0 ... [ 666.319401] Call Trace: [ 666.319405] [ 666.319408] dump_stack_lvl+0x53/0x70 [ 666.319412] print_address_description.constprop.0+0x2c/0x3b0 [ 666.319418] print_report+0xbe/0x2b0 [ 666.319421] ? mptcp_userspace_pm_get_local_id+0x1dc/0x1f0 [ 666.319423] kasan_report+0xce/0x100 [ 666.319426] ? mptcp_userspace_pm_get_local_id+0x1dc/0x1f0 [ 666.319429] mptcp_userspace_pm_get_local_id+0x1dc/0x1f0 [ 666.319433] mptcp_pm_get_local_id+0x371/0x440 ... [ 666.319821] Allocated by task 45539: [ 666.319844] kasan_save_stack+0x33/0x60 [ 666.319855] kasan_save_track+0x14/0x30 [ 666.319858] __kasan_kmalloc+0x8f/0xa0 [ 666.319863] __kmalloc_noprof+0x1e7/0x520 [ 666.319867] sock_kmalloc+0xdf/0x130 [ 666.319885] sock_kmemdup+0x1b/0x40 [ 666.319888] mptcp_userspace_pm_append_new_local_addr+0x261/0x500 [ 666.319910] mptcp_pm_nl_announce_doit+0x16a/0x610 ... [ 666.319967] Freed by task 45560: [ 666.319988] kasan_save_stack+0x33/0x60 [ 666.319991] kasan_save_track+0x14/0x30 [ 666.319994] kasan_save_free_info+0x3b/0x60 [ 666.319998] __kasan_slab_free+0x43/0x70 [ 666.320000] kfree+0x166/0x440 [ 666.320003] sock_kfree_s+0x1d/0x50 [ 666.320007] mptcp_userspace_pm_delete_local_addr.isra.0+0x157/0x200 [ 666.320011] mptcp_pm_nl_subflow_destroy_doit+0x51d/0xea0 Fix by copying the id into a local variable while still holding the lock, and use -1 as a "not found" sentinel. Fixes: f012d796a6de ("mptcp: check addrs list in userspace_pm_get_local_id") Cc: stable@vger.kernel.org Signed-off-by: Geliang Tang Tested-by: Xuanqiang Luo Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) --- net/mptcp/pm_userspace.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/net/mptcp/pm_userspace.c b/net/mptcp/pm_userspace.c index d100867e9202..945aa5afc2dd 100644 --- a/net/mptcp/pm_userspace.c +++ b/net/mptcp/pm_userspace.c @@ -132,12 +132,15 @@ int mptcp_userspace_pm_get_local_id(struct mptcp_sock= *msk, __be16 msk_sport =3D ((struct inet_sock *) inet_sk((struct sock *)msk))->inet_sport; struct mptcp_pm_addr_entry *entry; + int id; =20 spin_lock_bh(&msk->pm.lock); entry =3D mptcp_userspace_pm_lookup_addr(msk, &skc->addr); + id =3D entry ? entry->addr.id : -1; spin_unlock_bh(&msk->pm.lock); - if (entry) - return entry->addr.id; + + if (id !=3D -1) + return id; =20 if (skc->addr.port =3D=3D msk_sport) skc->addr.port =3D 0; --=20 2.53.0 From nobody Sat Jul 25 07:28:25 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 CF944442FBB; Tue, 21 Jul 2026 22:15:13 +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=1784672115; cv=none; b=TBI18vAG2Uz1FsKlKuWPTvJBhuDrBo4X2+DwsB5x8BmFzkZ79YIWsC6P7NZTcndV1uIL8fhzEZ2I0bJrAFttiQ01POzOOK407w1EVWFmSPiJ9oad5rEG54ns/ncckEwyFK8tcypBHS3X24ZPJR1xNld+fq7W96Nj2Ns+eOToWpY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784672115; c=relaxed/simple; bh=Hh/p/HQrYpss/cNZlPsOY5elFfI/RGjcLL6kRaGP9Yo=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=BH2sn8ru4YZu7pc6sUZdFAzUwFmpdlCHBe57gXw66CrWQOLvUHaVjeeedlZs1v95N5bYcRdrnQhn26dxtnUpQg/ZMcW9E4EkSCQhQY50ShiWvkmt4KrbYWXtAri41m71eG2K5MXFh/TaOkzDvpiGVPwqCqr2mo1kquEAAqI6CNs= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=kvSdE/Q0; 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="kvSdE/Q0" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9A27C1F00ACF; Tue, 21 Jul 2026 22:15:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1784672113; bh=ae4TnEnjRXKPyebXdwKey77J7n0LdGkmT+eRp+yVczk=; h=From:Date:Subject:References:In-Reply-To:To:Cc; b=kvSdE/Q0UXLke++yKv/arkXHmkZgrabKCetERpspki+9fyVNiMJz9B/uPhir3aHcN AyFmYmfQKzDj1zzKAIjGzeCL6NCguNgn6VfeUhCz+DVwX9cRfElneTZO2O145/I0JC w0XIBkPGUt8pWV17M9GcT3rn7cHq7N5GHq0oXD5b8xWXRs08PuZBwj63wuuuPrY3dE 2zWNL21QQgPhnwR8DQ8x31kX45dAzAOnqvtIQI0PQyEyZdooPzUlivAQyf7X4LIohZ rthaZ1nSlqPm4oH6QWDrIYnalXv1UmIw1XGZsyjZ9gy6crtV80B34sVSJF3SMWMFq9 N1XTADAG9tEHg== From: "Matthieu Baerts (NGI0)" Date: Wed, 22 Jul 2026 00:14:40 +0200 Subject: [PATCH net 3/5] mptcp: fix stale skb->sk reference on subflow close Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20260722-net-mptcp-misc-fixes-7-2-rc5-v1-3-6fb595bc86ef@kernel.org> References: <20260722-net-mptcp-misc-fixes-7-2-rc5-v1-0-6fb595bc86ef@kernel.org> In-Reply-To: <20260722-net-mptcp-misc-fixes-7-2-rc5-v1-0-6fb595bc86ef@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)" , Kalpan Jani , stable@vger.kernel.org X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openpgp-sha256; l=4474; i=matttbe@kernel.org; h=from:subject:message-id; bh=mIspUK790P4bSDJmTLrkzE/XviU2aKy8rWd6/M7/pQM=; b=owGbwMvMwCVWo/Th0Gd3rumMp9WSGLLi36dGZ9qcufuKe/PRFlP+iOMXxKeJ/48I9Ju5ouvL+ xrLjVend5SyMIhxMciKKbJIt0Xmz3xexVvi5WcBM4eVCWQIAxenAEzEsoORYf/pPfcsVrtuWHW4 5JTgLalYR2vJ10w7yh0de5fx9KRfKmNkOLW2lSMy476kfb3p24ZjX9YHMVne4rm4oeGhan0G2xY hdgA= X-Developer-Key: i=matttbe@kernel.org; a=openpgp; fpr=E8CB85F76877057A6E27F77AF6B7824F4269A073 From: Kalpan Jani The backlog list is updated by mptcp_data_ready() under mptcp_data_lock(). The cleanup of backlog references to a closing subflow, however, was performed in mptcp_close_ssk(), before __mptcp_close_ssk() acquires the ssk lock, and while holding neither the ssk lock nor mptcp_data_lock(). Because that traversal ran without mptcp_data_lock(), concurrent softirq RX processing on another CPU (subflow_data_ready() -> mptcp_data_ready() -> __mptcp_add_backlog(), under mptcp_data_lock()) could add a backlog entry referencing the ssk while the cleanup loop was in progress. Such an entry could be missed by the cleanup, or the concurrent list update could corrupt the traversal, leaving skb->sk pointing at the ssk after it is freed. A later mptcp_backlog_purge() then dereferences the stale pointer, triggering a warning in inet_sock_destruct() (ssk->sk_rmem_alloc !=3D 0) followed by a use-after-free in mptcp_backlog_purge(). Fix this by moving the backlog cleanup into __mptcp_close_ssk(), after subflow->closing is set to 1 and while the ssk lock is still held, serialized under mptcp_data_lock(). The cleanup runs only on the push path (MPTCP_CF_PUSH), where backlog references accumulate; on other teardown paths the caller already handles cleanup. With subflow->closing set and mptcp_data_lock() held across the purge, any concurrent mptcp_data_ready() either completes its enqueue before the purge runs and is caught, or observes closing=3D1 and bails out. Once mptcp_data_unlock() is reached, no new skb referencing the ssk can be enqueued, so the cleanup is exhaustive. Remove the unprotected traversal from mptcp_close_ssk() entirely. Fixes: ee458a3f314e ("mptcp: introduce mptcp-level backlog") Cc: stable@vger.kernel.org Suggested-by: Paolo Abeni Reported-by: Matthieu Baerts (NGI0) Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/621 Signed-off-by: Kalpan Jani Acked-by: Paolo Abeni Signed-off-by: Matthieu Baerts (NGI0) --- net/mptcp/protocol.c | 33 +++++++++++++++++++-------------- 1 file changed, 19 insertions(+), 14 deletions(-) diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c index b32f0cd262a7..ca644ec53eed 100644 --- a/net/mptcp/protocol.c +++ b/net/mptcp/protocol.c @@ -2545,6 +2545,22 @@ static void __mptcp_subflow_disconnect(struct sock *= ssk, } } =20 +static void mptcp_cleanup_ssk_backlog(struct sock *sk, struct sock *ssk) +{ + struct mptcp_sock *msk =3D mptcp_sk(sk); + struct sk_buff *skb; + + mptcp_data_lock(sk); + list_for_each_entry(skb, &msk->backlog_list, list) { + if (skb->sk !=3D ssk) + continue; + + atomic_sub(skb->truesize, &skb->sk->sk_rmem_alloc); + skb->sk =3D NULL; + } + mptcp_data_unlock(sk); +} + /* subflow sockets can be either outgoing (connect) or incoming * (accept). * @@ -2568,6 +2584,9 @@ static void __mptcp_close_ssk(struct sock *sk, struct= sock *ssk, lock_sock_nested(ssk, SINGLE_DEPTH_NESTING); subflow->closing =3D 1; =20 + if (flags & MPTCP_CF_PUSH) + mptcp_cleanup_ssk_backlog(sk, ssk); + /* Borrow the fwd allocated page left-over; fwd memory for the subflow * could be negative at this point, but will be reach zero soon - when * the data allocated using such fragment will be freed. @@ -2659,9 +2678,6 @@ static void __mptcp_close_ssk(struct sock *sk, struct= sock *ssk, void mptcp_close_ssk(struct sock *sk, struct sock *ssk, struct mptcp_subflow_context *subflow) { - struct mptcp_sock *msk =3D mptcp_sk(sk); - struct sk_buff *skb; - /* The first subflow can already be closed or disconnected */ if (subflow->close_event_done || READ_ONCE(subflow->local_id) < 0) return; @@ -2671,17 +2687,6 @@ void mptcp_close_ssk(struct sock *sk, struct sock *s= sk, if (sk->sk_state =3D=3D TCP_ESTABLISHED) mptcp_event(MPTCP_EVENT_SUB_CLOSED, mptcp_sk(sk), ssk, GFP_KERNEL); =20 - /* Remove any reference from the backlog to this ssk; backlog skbs consume - * space in the msk receive queue, no need to touch sk->sk_rmem_alloc - */ - list_for_each_entry(skb, &msk->backlog_list, list) { - if (skb->sk !=3D ssk) - continue; - - atomic_sub(skb->truesize, &skb->sk->sk_rmem_alloc); - skb->sk =3D NULL; - } - /* subflow aborted before reaching the fully_established status * attempt the creation of the next subflow */ --=20 2.53.0 From nobody Sat Jul 25 07:28:25 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 9A628443AAF; Tue, 21 Jul 2026 22:15:16 +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=1784672118; cv=none; b=Pu57AQdIdvQ/X8ml8g87f+/ash+r2yPPn2rHmbbafVkWqKqjMlJcvGFGQjiZpX+rMRa/G80r/9bLg+ZnxUYhFw9Q8Ig9c6PBTV2Apx+uhChvVOwRulYJhVT9q05kI2gA+Uw1EdRndozD8MEv7ZC82FD29HLe23LeEberedu3VaM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784672118; c=relaxed/simple; bh=cQebUUc3b4trxwzXFkPnBUl35n/3pGClyHHp+w9wnHE=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=l5i4HJkDyXaCptSRGaOVxE08ybjpXUZWy/4+T4mo/AixiJftEchQo3BHgzHBmpV/xVBZHUC42aQ2kK629Y3EqRKDQsxbsMZSDBZ1GjvaTjqJ4QGAbE1c3zP2X2AeonvWeRGZWATzU3V7UiG71rd5EwS7h7/5teblyBryd22101E= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=E9QOAxV8; 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="E9QOAxV8" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 22D431F00A3A; Tue, 21 Jul 2026 22:15:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1784672116; bh=LA1GN88xFwR/n7V23hRxm12Z3KevDKUurEIo5L4Unic=; h=From:Date:Subject:References:In-Reply-To:To:Cc; b=E9QOAxV8AEuVIl2eI/NS9SD6Fa83K9SYKz3OOc+eOd1cnZucKEG/N1hcTv2gZkIzV 7AypNaLHOYJykI6Kn9qK5hMImnmcZSCsParRJLhCdWQ2pOj38Fl9KUcPhIZRfV2dGp 12/i5GGDrjA6cQYouT6PWQJppzVVbHlLO3GLbD8DfgM6OHHilOnz/1VXUVOICIJlOk pCHg7Yug997qB4ayD2kMqUNmzGS/ccER7z05AlkSAaz313OB8YxqdptOIa0UoeGZWC TuJYfpGMCPMUtHOswAAXNQ4HlPXHfA4YxomUbAHccs8HFzFPveMNXJ8Fmx2jePNv8v gXwhhooPdQ60g== From: "Matthieu Baerts (NGI0)" Date: Wed, 22 Jul 2026 00:14:41 +0200 Subject: [PATCH net 4/5] selftests: mptcp: userspace_pm: fix undefined variable port 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: <20260722-net-mptcp-misc-fixes-7-2-rc5-v1-4-6fb595bc86ef@kernel.org> References: <20260722-net-mptcp-misc-fixes-7-2-rc5-v1-0-6fb595bc86ef@kernel.org> In-Reply-To: <20260722-net-mptcp-misc-fixes-7-2-rc5-v1-0-6fb595bc86ef@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, Shuah Khan , linux-kselftest@vger.kernel.org, Geliang Tang X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openpgp-sha256; l=1857; i=matttbe@kernel.org; h=from:subject:message-id; bh=AAR5vqT0rqrRZnOlgAxMfAI48G7bJDKuLQu6poOze3I=; b=owGbwMvMwCVWo/Th0Gd3rumMp9WSGLLi36eeWXXTOoxDVJLpzLO5DyxWetyzc153WcX9l/iDV 6dkHUNdO0pZGMS4GGTFFFmk2yLzZz6v4i3x8rOAmcPKBDKEgYtTACZiNoPhn8KUKUu/mvTz6Ie+ zdsQnSXTfP4dg+ey7jQpQY639k+CXzD8T/6f2psfrl/3oeLRgnBupia2teJPJS+/cbkY3qhwnse VAwA= X-Developer-Key: i=matttbe@kernel.org; a=openpgp; fpr=E8CB85F76877057A6E27F77AF6B7824F4269A073 From: Geliang Tang In make_connection(), the variable "port" is used but never defined. This leads to an empty argument being passed to wait_local_port_listen(), causing "printf: : invalid number" errors: # INFO: Init # 01 Created network namespaces ns1, ns2 [ OK ] # INFO: Make connections # ./../lib.sh: line 651: printf: : invalid number # 02 Established IPv4 MPTCP Connection ns2 =3D> ns1 [ OK ] # INFO: Connection info: 10.0.1.2:59516 -> 10.0.1.1:50002 # ./../lib.sh: line 651: printf: : invalid number # 03 Established IPv6 MPTCP Connection ns2 =3D> ns1 [ OK ] Fix it by using the correctly defined variable "app_port", which holds the appropriate port number for the connection. Fixes: 39348f5f2f13 ("selftests: mptcp: wait for port instead of sleep") Cc: stable@vger.kernel.org Signed-off-by: Geliang Tang Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) --- To: Shuah Khan Cc: linux-kselftest@vger.kernel.org --- tools/testing/selftests/net/mptcp/userspace_pm.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/testing/selftests/net/mptcp/userspace_pm.sh b/tools/test= ing/selftests/net/mptcp/userspace_pm.sh index e9ae1806ab07..30a809752d1b 100755 --- a/tools/testing/selftests/net/mptcp/userspace_pm.sh +++ b/tools/testing/selftests/net/mptcp/userspace_pm.sh @@ -212,7 +212,7 @@ make_connection() ./mptcp_connect -s MPTCP -w 300 -p $app_port -l $listen_addr > /dev/nu= ll 2>&1 & local server_pid=3D$! =20 - mptcp_lib_wait_local_port_listen "${ns1}" "${port}" + mptcp_lib_wait_local_port_listen "${ns1}" "${app_port}" =20 # Run the client, transfer $file and stay connected to the server # to conduct tests --=20 2.53.0 From nobody Sat Jul 25 07:28:25 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 7C4E4445AE4; Tue, 21 Jul 2026 22:15:19 +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=1784672120; cv=none; b=QZxqn+gZByCikME9ikseI8xYPbXtTIMJaPIDqRHkCDKlOSkKnKepO5wB2Tj5KqT0UWvAZorfEKOvf/zTIkiIKBJy6FqTeGfY89epDvGJlagXGUjSz28tl58O22gkKGqr471dXkURsOg0CQnvSDWKb1GA43UmyRN0wPZwcUR5HxM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784672120; c=relaxed/simple; bh=tSKdsuqUcnutK73kjhNzdNGzUK+YT2RybfzYqFoiXRE=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=nE5ICDOPugV8OdEjPNuqD2CN/MTDvXPnsrg/PjszOc49zGy6KUBJbtvrin0SOYzcgO07hqWD4zEBk3VD2Q9WqdAxuSC68ZLXeYKGwTmIpnOcdjdtpxnlbCjgnLi27f4znkWJCHmza/ow+LsOO1pAzLk5j6FkEWdei4SoVYzCLZI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Fu3RwrtD; 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="Fu3RwrtD" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C582B1F00A3D; Tue, 21 Jul 2026 22:15:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1784672119; bh=eDNl95CZQ/T901YSIPfRI4wV+4KqYKa1GvmpSJZDq10=; h=From:Date:Subject:References:In-Reply-To:To:Cc; b=Fu3RwrtDdBp7DxmxD3qqiqk3jcIcnK6yNdKYxLVVrPMUIF2eMb/4kZpQvjOKugO2m BqQjrOTa3bfRLFj/kQFHFkGc7D5d1wwzZzd6QJk42aZyLBsXiCXhrshFRVD5Xq5Rg7 pgNBDRvVr1ZWVRC9WxqpiS8Z7RrAbjxITjRqIvKaAbcKvkKTlVkBko5JTCROa/desn XiGWEvtel96JpZQeXsM0lw35DD3Qg5vm8Hw6XPrT1HCTXNTUpxwvgIqrB5xnwoYBGz /dRH6qOwNOo+q936hjSl2jnfTnuMdWWkEQPUBUSpptyDi2FJOr0dXm8W2HYhr/bBeo NccHvd8eas9bw== From: "Matthieu Baerts (NGI0)" Date: Wed, 22 Jul 2026 00:14:42 +0200 Subject: [PATCH net 5/5] mptcp: fix BUILD_BUG_ON on legacy ARM config 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: <20260722-net-mptcp-misc-fixes-7-2-rc5-v1-5-6fb595bc86ef@kernel.org> References: <20260722-net-mptcp-misc-fixes-7-2-rc5-v1-0-6fb595bc86ef@kernel.org> In-Reply-To: <20260722-net-mptcp-misc-fixes-7-2-rc5-v1-0-6fb595bc86ef@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, Frank Ranner , kernel test robot X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openpgp-sha256; l=1973; i=matttbe@kernel.org; h=from:subject:message-id; bh=tSKdsuqUcnutK73kjhNzdNGzUK+YT2RybfzYqFoiXRE=; b=owGbwMvMwCVWo/Th0Gd3rumMp9WSGLLi36dV2+zMla1sWiTPtfNaWMOE+ijGS75RczsetVTdK a1OZbDrKGVhEONikBVTZJFui8yf+byKt8TLzwJmDisTyBAGLk4BmEhwAcP/DKYniqrsF6r8pps2 LV2+/2f/tfU3uYVc8uITtrRma5S8YGR4ONdz06y1hzae3/ezxsrW3OY6851XT5cy3doU/a+Ci0W aGwA= X-Developer-Key: i=matttbe@kernel.org; a=openpgp; fpr=E8CB85F76877057A6E27F77AF6B7824F4269A073 The 0-day bot managed to find kernel configs that cause build failures, e.g. when using the StrongARM SA1100 target (ARMv4). On such legacy ARM architecture, all structures are apparently aligned to 32 bits, causing build issue here. Indeed, on such architecture, 'flags' size is not equivalent to sizeof(u16) as expected, but to sizeof(u32). Instead, use memset(). It was not used before to ensure a simple clear operation was used by the compiler. But at the end, it shouldn't matter, and the compiler should optimise this to the same operation with or without memset() when -O above 0 is used. So let's switch to memset() to fix this issue, and reduce this complexity. Fixes: 5e939544f9d2 ("mptcp: fix uninit-value in mptcp_established_options") Cc: stable@vger.kernel.org Suggested-by: Frank Ranner Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202605312026.Srgsz7Tp-lkp@int= el.com/ Closes: https://lore.kernel.org/oe-kbuild-all/202607031100.upQfRZTM-lkp@int= el.com/ Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts (NGI0) --- net/mptcp/options.c | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/net/mptcp/options.c b/net/mptcp/options.c index 1b74ca5b6a59..c664023d37ba 100644 --- a/net/mptcp/options.c +++ b/net/mptcp/options.c @@ -571,10 +571,7 @@ static bool mptcp_established_options_dss(struct sock = *sk, struct sk_buff *skb, bool ret =3D false; =20 /* Zero `use_ack` and `use_map` flags with one shot. */ - BUILD_BUG_ON(sizeof_field(struct mptcp_ext, flags) !=3D sizeof(u16)); - BUILD_BUG_ON(!IS_ALIGNED(offsetof(struct mptcp_ext, flags), - sizeof(u16))); - *(u16 *)&opts->ext_copy.flags =3D 0; + memset(&opts->ext_copy.flags, 0, sizeof(opts->ext_copy.flags)); opts->csum_reqd =3D READ_ONCE(msk->csum_enabled); mpext =3D skb ? mptcp_get_ext(skb) : NULL; =20 --=20 2.53.0