From: Paolo Abeni <pabeni@redhat.com>
To: Harshit Varu <harshitvaru666@gmail.com>, netdev@vger.kernel.org
Cc: mptcp@lists.linux.dev, matttbe@kernel.org, martineau@kernel.org,
security@kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH mptcp v2] mptcp: restore full join state in syncookie MP_JOIN reconstruction
Date: Wed, 12 Aug 2026 11:10:08 +0200 [thread overview]
Message-ID: <d98287c8-0925-4e70-8cb7-c5703d8145fa@redhat.com> (raw)
In-Reply-To: <20260811222325.90426-1-harshitvaru666@gmail.com>
On 8/12/26 12:23 AM, Harshit Varu wrote:
> mptcp_token_join_cookie_init_state() rebuilds the request socket for a
> MP_JOIN 4th-ACK that was handled under SYN cookies, but it only restores
> remote_nonce, local_nonce, backup, join_id, token and msk from the saved
> cookie entry. local_id, request_bkup and thmac are never restored, even
> though the SYN path saves local_id and computes the other two.
>
> subflow_ulp_clone() then reads those three fields and copies them into the
> joined subflow context (local_id, request_bkup, thmac). Because the
> request-sock slab is SLAB_TYPESAFE_BY_RCU and not zeroed on allocation, the
> values are stale bytes of previously freed request sockets, which an
> off-path peer can influence by sending concurrent MP_JOIN SYNs. A corrupted
> local_id breaks id-based path-manager bookkeeping, and a corrupted
> request_bkup misclassifies the subflow in the packet scheduler's
> backup/active selection.
>
> Save and restore request_bkup and thmac as well, completing the state
> restore.
>
> Fixes: 9466a1ccebbe ("mptcp: enable JOIN requests even if cookies are in use")
> Cc: stable@vger.kernel.org
> Assisted-by: opencode:deepseek-v4-flash
> Signed-off-by: Harshit Varu <harshitvaru666@gmail.com>
> ---
> net/mptcp/syncookies.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/net/mptcp/syncookies.c b/net/mptcp/syncookies.c
> index 7f2252634..3c25ff627 100644
> --- a/net/mptcp/syncookies.c
> +++ b/net/mptcp/syncookies.c
> @@ -27,7 +27,9 @@ struct join_entry {
> u8 join_id;
> u8 local_id;
> u8 backup;
> + u8 request_bkup;
> u8 valid;
> + u64 thmac;
Is thmac used for passive flows after
mptcp_token_join_cookie_init_state()? I think it's not. If so just init
to 0 in mptcp_token_join_cookie_init_state (with a comment) and remove
remove the new field from here.
Same for request_bkup, AFAICS both are used in syn_ack only.
The bottom line is that we don't want to increase `struct join_entry`
size without good reasons.
/P
next prev parent reply other threads:[~2026-08-12 9:10 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-11 21:51 [PATCH mptcp] mptcp: fix uninitialized local_id in syncookie MP_JOIN reconstruction Harshit Varu
2026-08-11 22:08 ` sashiko-bot
2026-08-11 22:23 ` [PATCH mptcp v2] mptcp: restore full join state " Harshit Varu
2026-08-11 23:43 ` MPTCP CI
2026-08-12 9:10 ` Paolo Abeni [this message]
2026-08-11 23:00 ` [PATCH mptcp] mptcp: fix uninitialized local_id " MPTCP CI
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d98287c8-0925-4e70-8cb7-c5703d8145fa@redhat.com \
--to=pabeni@redhat.com \
--cc=harshitvaru666@gmail.com \
--cc=martineau@kernel.org \
--cc=matttbe@kernel.org \
--cc=mptcp@lists.linux.dev \
--cc=netdev@vger.kernel.org \
--cc=security@kernel.org \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.