On Thu, May 25, 2017 at 11:08 PM, Wei Sun <w...@cse.unl.edu> wrote:
>
> Hi there,
>
> we find a special case for Linux TCP undo operations where
> tp->snd_cwnd could be extremely large (e.g., 4294967294) by two
> consecutive cwnd undo operations when using
> reno/veno/vegas/highspeed/HTCP/yeah/westwood/hybla/illinois/scalable/lp
> congestion control algorithms in the latest long-term kernel 4.9.
>
> e.g., a simple trace for sender-side tcp state variables
> cwnd ssthresh ca_state
> 10 2147483647 0
> 10 2147483647 0
> 1 5 4
> 11 2147483647 4 first
> undo operation
> 4294967294 2147483647 0 second undo operation
> 4294967294 2147483647 0
>
>
> By debugging the code, we find that the second undo operation was
> triggered by F-RTO mechanism without checking current tp->undo_marker.
>
> The case should be existing for all kernel versions depending on F-RTO
> internals (i.e., this bug exists for kernels 4.10 and earlier)
Thanks for discovering that. Note this issue is addressed by
commit 89fe18e44f7ee5ab1c90d0dff5835acee7751427
Author: Yuchung Cheng <ych...@google.com>
Date: Thu Jan 12 22:11:37 2017 -0800
tcp: extend F-RTO to catch more spurious timeouts
>
>
> Just Let you know in case of some vulnerabilities as it is not hard to
> trigger this specific case.
>
> Attached is a simple Google's packetdrill script to trigger it and a
> possible patch to fix it. Thanks
