netdev - Re: [PATCH v2 net-next 0/2] tcp: Make simultaneous connect() RFC-compliant.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20240710164740.85061-1-kuniyu@amazon.com>
Date: Wed, 10 Jul 2024 09:47:40 -0700
From: Kuniyuki Iwashima <kuniyu@...zon.com>
To: <kuniyu@...zon.com>
CC: <davem@...emloft.net>, <dima@...sta.com>, <dsahern@...nel.org>,
	<edumazet@...gle.com>, <kuba@...nel.org>, <kuni1840@...il.com>,
	<netdev@...r.kernel.org>, <pabeni@...hat.com>
Subject: Re: [PATCH v2 net-next 0/2] tcp: Make simultaneous connect() RFC-compliant.

From: Kuniyuki Iwashima <kuniyu@...zon.com>
Date: Tue, 9 Jul 2024 18:44:55 -0700
> From: Jakub Kicinski <kuba@...nel.org>
> Date: Tue, 9 Jul 2024 12:52:09 -0700
> > On Mon, 8 Jul 2024 11:08:50 -0700 Kuniyuki Iwashima wrote:
> > >   * Add patch 2
> > 
> > Hi Kuniyuki!
> > 
> > Looks like it also makes BPF CI fail. All of these:
> > https://netdev.bots.linux.dev/contest.html?branch=net-next-2024-07-09--15-00&executor=gh-bpf-ci&pw-n=0
> > But it builds down to the reuseport test on various platforms.
> 
> Oh, thanks for catching!
> 
> It seems the test is using TFO, and somehow fastopen_rsk is cleared,
> but a packet is processed later in SYN_RECV state...

The test used MSG_FASTOPEN but TFO always failed due to lack of
proper configuration, this should be fixed.

IP 127.0.0.1.36477 > 127.0.0.1.53357: Flags [S], seq 2263448885:2263448893, win 65495, options [mss 65495,sackOK,TS val 2871616407 ecr 0,nop,wscale 7], length 8
IP 127.0.0.1.53357 > 127.0.0.1.36477: Flags [S.], seq 3767023264, ack 2263448886, win 65483, options [mss 65495,sackOK,TS val 2871616407 ecr 2871616407,nop,wscale 7], length 0

But this wasn't related, just red-herring.

I just missed that the ACK of 3WHS was also processed by newly created
SYN_RECV sk in tcp_rcv_state_process() called from tcp_child_process().

So, (sk->sk_state == TCP_SYN_RECV && !tp->fastopen_rsk) cannot deduce
the cross SYN+ACK case.

We need to use (sk->sk_state == TCP_SYN_RECV && sk->sk_socket).

Will post v3.

Thanks!