All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthieu Baerts <matttbe@kernel.org>
To: Paolo Abeni <pabeni@redhat.com>,
	Harshit Varu <harshitvaru666@gmail.com>,
	netdev@vger.kernel.org
Cc: mptcp@lists.linux.dev, 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: Sat, 15 Aug 2026 00:56:33 +0200	[thread overview]
Message-ID: <fd6e2e14-4fd2-42fb-8edf-818fe9e90a38@kernel.org> (raw)
In-Reply-To: <d98287c8-0925-4e70-8cb7-c5703d8145fa@redhat.com>

Hi Harshit, Paolo,

@Paolo: thank you for the review!

On 12/08/2026 11:10, Paolo Abeni wrote:
> 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.

@Harshit: I agree with Paolo. So at the end, the v1 was good.

Can you please send a new version with what you had in the v1? Before
you do so, I have a few requests:

- Do not send a new version as a reply to another [1]

- Use 'PATCH net' [1]

- Wait 24h between submissions [1]

- Remove 'security@k.o' from Cc as it is sent to public MLs [2]

- Use ./scripts/get_maintainer.pl to cc the right people [3]

[1] https://docs.kernel.org/process/maintainer-netdev.html
[2] https://docs.kernel.org/process/submitting-patches.html
[3]
https://netdev-ctrl.bots.linux.dev/logs/build/1144354/14744385/cc_maintainers/desc

Cheers,
Matt
-- 
Sponsored by the NGI0 Core fund.


  reply	other threads:[~2026-08-14 22:56 UTC|newest]

Thread overview: 7+ 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
2026-08-14 22:56     ` Matthieu Baerts [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=fd6e2e14-4fd2-42fb-8edf-818fe9e90a38@kernel.org \
    --to=matttbe@kernel.org \
    --cc=harshitvaru666@gmail.com \
    --cc=martineau@kernel.org \
    --cc=mptcp@lists.linux.dev \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --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.