netdev - Re: [PATCH net] tcp: clear tp->retrans_stamp in tcp_rcv_fastopen

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: 
 <171867302909.10892.3043137715389304711.git-patchwork-notify@kernel.org>
Date: Tue, 18 Jun 2024 01:10:29 +0000
From: patchwork-bot+netdevbpf@...nel.org
To: Eric Dumazet <edumazet@...gle.com>
Cc: davem@...emloft.net, kuba@...nel.org, pabeni@...hat.com,
 netdev@...r.kernel.org, eric.dumazet@...il.com, stable@...r.kernel.org,
 ncardwell@...gle.com, ycheng@...gle.com
Subject: Re: [PATCH net] tcp: clear tp->retrans_stamp in tcp_rcv_fastopen_synack()

Hello:

This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@...nel.org>:

On Fri, 14 Jun 2024 13:06:15 +0000 you wrote:
> Some applications were reporting ETIMEDOUT errors on apparently
> good looking flows, according to packet dumps.
> 
> We were able to root cause the issue to an accidental setting
> of tp->retrans_stamp in the following scenario:
> 
> - client sends TFO SYN with data.
> - server has TFO disabled, ACKs only SYN but not payload.
> - client receives SYNACK covering only SYN.
> - tcp_ack() eats SYN and sets tp->retrans_stamp to 0.
> - tcp_rcv_fastopen_synack() calls tcp_xmit_retransmit_queue()
>   to retransmit TFO payload w/o SYN, sets tp->retrans_stamp to "now",
>   but we are not in any loss recovery state.
> - TFO payload is ACKed.
> - we are not in any loss recovery state, and don't see any dupacks,
>   so we don't get to any code path that clears tp->retrans_stamp.
> - tp->retrans_stamp stays non-zero for the lifetime of the connection.
> - after first RTO, tcp_clamp_rto_to_user_timeout() clamps second RTO
>   to 1 jiffy due to bogus tp->retrans_stamp.
> - on clamped RTO with non-zero icsk_retransmits, retransmits_timed_out()
>   sets start_ts from tp->retrans_stamp from TFO payload retransmit
>   hours/days ago, and computes bogus long elapsed time for loss recovery,
>   and suffers ETIMEDOUT early.
> 
> [...]

Here is the summary with links:
  - [net] tcp: clear tp->retrans_stamp in tcp_rcv_fastopen_synack()
    https://git.kernel.org/netdev/net/c/9e046bb111f1

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html