[PATCH mptcp] mptcp: fix uninitialized local_id in syncookie MP_JOIN reconstruction

[PATCH mptcp] mptcp: fix uninitialized local_id in syncookie MP_JOIN reconstruction

[Harshit Varu]

mptcp_token_join_cookie_init_state() restores remote_nonce, local_nonce,
backup, join_id, token and msk from the saved cookie entry when rebuilding
the request socket for a MP_JOIN 4th-ACK handled under SYN cookies, but it
does not restore local_id, even though the SYN path saved it.
subflow_ulp_clone() then reads that uninitialized field and stores it as
the joined subflow's address-ID. Because the request-sock slab is
SLAB_TYPESAFE_BY_RCU and not zeroed on allocation, the value is the stale
byte of a previously freed request socket, which an off-path peer can
influence by sending concurrent MP_JOIN SYNs. This corrupts the path
manager's id-based subflow bookkeeping for the connection.

Restore subflow_req->local_id from the cookie entry, as done for the other
fields.

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 | 1 +
 1 file changed, 1 insertion(+)

diff --git a/net/mptcp/syncookies.c b/net/mptcp/syncookies.c
index 7f2252634..b5cac5701 100644
--- a/net/mptcp/syncookies.c
+++ b/net/mptcp/syncookies.c
@@ -118,6 +118,7 @@ bool mptcp_token_join_cookie_init_state(struct mptcp_subflow_request_sock *subfl
 	subflow_req->local_nonce = e->local_nonce;
 	subflow_req->backup = e->backup;
 	subflow_req->remote_id = e->join_id;
+	subflow_req->local_id = e->local_id;
 	subflow_req->token = e->token;
 	subflow_req->msk = msk;
 	spin_unlock_bh(&join_entry_locks[i]);
-- 
2.53.0

[PATCH mptcp v2] mptcp: restore full join state in syncookie MP_JOIN reconstruction

[Harshit Varu]

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;
 };
 
 #define COOKIE_JOIN_SLOTS	1024
@@ -63,8 +65,10 @@ static void mptcp_join_store_state(struct join_entry *entry,
 	entry->remote_nonce = subflow_req->remote_nonce;
 	entry->local_nonce = subflow_req->local_nonce;
 	entry->backup = subflow_req->backup;
+	entry->request_bkup = subflow_req->request_bkup;
 	entry->join_id = subflow_req->remote_id;
 	entry->local_id = subflow_req->local_id;
+	entry->thmac = subflow_req->thmac;
 	entry->valid = 1;
 }
 
@@ -117,8 +121,11 @@ bool mptcp_token_join_cookie_init_state(struct mptcp_subflow_request_sock *subfl
 	subflow_req->remote_nonce = e->remote_nonce;
 	subflow_req->local_nonce = e->local_nonce;
 	subflow_req->backup = e->backup;
+	subflow_req->request_bkup = e->request_bkup;
 	subflow_req->remote_id = e->join_id;
+	subflow_req->local_id = e->local_id;
 	subflow_req->token = e->token;
+	subflow_req->thmac = e->thmac;
 	subflow_req->msk = msk;
 	spin_unlock_bh(&join_entry_locks[i]);
 	return true;
-- 
2.53.0

Re: [PATCH mptcp v2] mptcp: restore full join state in syncookie MP_JOIN reconstruction

[Paolo Abeni]

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