All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthieu Baerts <matttbe@kernel.org>
To: Paolo Abeni <pabeni@redhat.com>, mptcp@lists.linux.dev
Subject: Re: [PATCH mptcp-net] mptcp: fallback earlier on simult connection
Date: Tue, 2 Dec 2025 12:03:20 +0100	[thread overview]
Message-ID: <25ab27c2-28e4-4604-bf9b-c17661c032da@kernel.org> (raw)
In-Reply-To: <fdf749ae-ec10-4809-957e-be2737241650@kernel.org>

Hi Paolo,

On 01/12/2025 18:35, Matthieu Baerts wrote:
> Hi Paolo,
> 
> On 28/11/2025 13:22, Paolo Abeni wrote:
>> Syzkaller reports a simult-connect race leading to inconsistent fallback
>> status:
> 
> (...)
> 
>> The TCP subflow can process the simult-connect syn-ack packet after
>> transitioning to TCP_FIN1 state, bypassing the MPTCP fallback check,
>> as the sk_state_change() callback is not invoked for * -> FIN_WAIT1
>> transitions.
>>
>> That will move the msk socket to an inconsistent status and the next
>> incoming data will hit the reported splat.
>>
>> Close the race moving the simult-fallback check at the earliest possible
>> stage - that is at syn-ack generation time.
> 
> Good idea!
> 
>> Fixes: 23e89e8ee7be ("tcp: Don't drop SYN+ACK for simultaneous connect().")
> 
> From what I understand, the modification on TCP side is needed for this
> fix. When reading its commit message, it sounds it should have contained
> a Fixes tag, but net-next was chosen to delay the fix. Is that correct?
> 
> If yes, should I ask to backport this other commit with this patch? Or
> should this patch be backported only up to stable trees already having
> this other commit?
> 
>> Fixes: 4fd19a307016 ("mptcp: fix inconsistent state on fastopen race")
>> Fixes: 1e777f39b4d7 ("mptcp: add MSG_FASTOPEN sendmsg flag support")> Reported-by: syzbot+0ff6b771b4f7a5bce83b@syzkaller.appspotmail.com
>> Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/586
>> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
>> ---
>> @mattbe: could you please test vs yours syz repro?
> 
> In progress!

Sorry for the delay, I had some issues with my setup.

I can still reproduce with your patch and my reproducer. I have added
more details on:

  https://github.com/multipath-tcp/mptcp_net-next/issues/586

I can easily reproduce it now, and the issue might be slightly different
from the one identified by syzbot.

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


      reply	other threads:[~2025-12-02 11:03 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-28 12:22 [PATCH mptcp-net] mptcp: fallback earlier on simult connection Paolo Abeni
2025-11-28 13:35 ` MPTCP CI
2025-12-01 11:10   ` Paolo Abeni
2025-12-01 11:19     ` Matthieu Baerts
2025-12-01 17:35 ` Matthieu Baerts
2025-12-02 11:03   ` Matthieu Baerts [this message]

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=25ab27c2-28e4-4604-bf9b-c17661c032da@kernel.org \
    --to=matttbe@kernel.org \
    --cc=mptcp@lists.linux.dev \
    --cc=pabeni@redhat.com \
    /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.