netdev - Re: A bug report for Linux TCP congestion control algorithms

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: <CAK6E8=fHMNmAvxhpi3A5Wgf7UJ=UivUShL6nD62SK=g8BfdVMw@mail.gmail.com>
Date:   Fri, 26 May 2017 09:51:58 -0700
From:   Yuchung Cheng <ycheng@...gle.com>
To:     Wei Sun <wsun@....unl.edu>
Cc:     netdev <netdev@...r.kernel.org>
Subject: Re: A bug report for Linux TCP congestion control algorithms

On Thu, May 25, 2017 at 11:08 PM, Wei Sun <wsun@....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 <ycheng@...gle.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