netdev - Re: [PATCH v2 net] tcp: fix retrans timestamp on passive Fast Open

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: <20190514.151907.811132511902610611.davem@davemloft.net>
Date:   Tue, 14 May 2019 15:19:07 -0700 (PDT)
From:   David Miller <davem@...emloft.net>
To:     ycheng@...gle.com
Cc:     netdev@...r.kernel.org, ncardwell@...gle.com
Subject: Re: [PATCH v2 net] tcp: fix retrans timestamp on passive Fast Open

From: Yuchung Cheng <ycheng@...gle.com>
Date: Mon, 13 May 2019 10:32:05 -0700

> Commit c7d13c8faa74 ("tcp: properly track retry time on
> passive Fast Open") sets the start of SYNACK retransmission
> time on passive Fast Open in "retrans_stamp". However the
> timestamp is not reset upon the handshake has completed. As a
> result, future data packet retransmission may not update it in
> tcp_retransmit_skb(). This may lead to socket aborting earlier
> unexpectedly by retransmits_timed_out() since retrans_stamp remains
> the SYNACK rtx time.
> 
> This bug only manifests on passive TFO sender that a) suffered
> SYNACK timeout and then b) stalls on very first loss recovery. Any
> successful loss recovery would reset the timestamp to avoid this
> issue.
> 
> Fixes: c7d13c8faa74 ("tcp: properly track retry time on passive Fast Open")
> Signed-off-by: Yuchung Cheng <ycheng@...gle.com>
> Signed-off-by: Neal Cardwell <ncardwell@...gle.com>

Applied and queued up for -stable, thanks.