netdev - Re: [PATCH net] tcp: fix ssthresh and undo for consecutive short FRTO episodes

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: <20140814.144106.1946147822858723625.davem@redhat.com>
Date:	Thu, 14 Aug 2014 14:41:06 -0700 (PDT)
From:	David Miller <davem@...hat.com>
To:	ncardwell@...gle.com
Cc:	netdev@...r.kernel.org, ycheng@...gle.com
Subject: Re: [PATCH net] tcp: fix ssthresh and undo for consecutive short
 FRTO episodes

From: Neal Cardwell <ncardwell@...gle.com>
Date: Thu, 14 Aug 2014 16:13:07 -0400

> Fix TCP FRTO logic so that it always notices when snd_una advances,
> indicating that any RTO after that point will be a new and distinct
> loss episode.
> 
> Previously there was a very specific sequence that could cause FRTO to
> fail to notice a new loss episode had started:
> 
> (1) RTO timer fires, enter FRTO and retransmit packet 1 in write queue
> (2) receiver ACKs packet 1
> (3) FRTO sends 2 more packets
> (4) RTO timer fires again (should start a new loss episode)
> 
> The problem was in step (3) above, where tcp_process_loss() returned
> early (in the spot marked "Step 2.b"), so that it never got to the
> logic to clear icsk_retransmits. Thus icsk_retransmits stayed
> non-zero. Thus in step (4) tcp_enter_loss() would see the non-zero
> icsk_retransmits, decide that this RTO is not a new episode, and
> decide not to cut ssthresh and remember the current cwnd and ssthresh
> for undo.
> 
> There were two main consequences to the bug that we have
> observed. First, ssthresh was not decreased in step (4). Second, when
> there was a series of such FRTO (1-4) sequences that happened to be
> followed by an FRTO undo, we would restore the cwnd and ssthresh from
> before the entire series started (instead of the cwnd and ssthresh
> from before the most recent RTO). This could result in cwnd and
> ssthresh being restored to values much bigger than the proper values.
> 
> Signed-off-by: Neal Cardwell <ncardwell@...gle.com>
> Signed-off-by: Yuchung Cheng <ycheng@...gle.com>
> Fixes: e33099f96d99c ("tcp: implement RFC5682 F-RTO")

Applied and queued up for -stable, thanks.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html