Re: [PATCH net-next v1] tcp: fix spurious RST during three-way handshake

From: Kuniyuki Iwashima
Date: Thu Sep 25 2025 - 13:42:19 EST


On Thu, Sep 25, 2025 at 6:11 AM Jiayuan Chen <jiayuan.chen@xxxxxxxxx> wrote:
>
> When the server receives the final ACK of the three-way handshake,
> tcp_v4_syn_recv_sock::inet_ehash_nolisten::inet_ehash_insert() first
> removes the request_sock from the ehash bucket and then inserts the
> newly created child sock. This creates a race window where the first
> incoming data packet from the client can fail to find either an
> ESTABLISHED or SYN_RECV socket, causing the server to send a spurious RST.
>
> The root cause is the lockless lookup in __inet_lookup_established(). A
> concurrent lookup operation may not find any valid socket during the brief
> period between the removal of the request_sock and the insertion of the
> child sock.
>
> To fix this and keep lockless lookup, we need:
> 1. Insert the child sock into the ehash bucket first.
> 2. Then remove the request_sock.
>
> This ensures the bucket is never left empty during the transition.
>
> The original inet_ehash_insert() logic first attempted to remove osk,
> inserting sk only upon successful removal. We changed this to:
> check for osk's existence first. If present, insert sk before removing osk
> (ensuring the bucket isn't empty). If osk is absent, take no action. This
> maintains the original function's intent while eliminating the window where
> the hashtable bucket is empty.
>
> Both sockets briefly coexist in the bucket. During this short window, new
> lookups correctly find the child socket. For a packet that has already
> started its lookup and finds the lingering request_sock, this is also safe
> because inet_csk_complete_hashdance() contains the necessary checks to
> prevent the creation of multiple child sockets for the same connection.
>
> Fixes: 079096f103fac ("tcp/dccp: install syn_recv requests into ehash table")
> Signed-off-by: Jiayuan Chen <jiayuan.chen@xxxxxxxxx>

Xuanqiang is working on the fix.

https://lore.kernel.org/netdev/20250925021628.886203-1-xuanqiang.luo@xxxxxxxxx/