netdev - 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-next>] [day] [month] [year] [list]

Date:   Fri, 26 May 2017 01:08:34 -0500
From:   Wei Sun <wsun@....unl.edu>
To:     netdev@...r.kernel.org
Subject: A bug report for Linux TCP congestion control algorithms

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)

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

View attachment "path.diff" of type "text/plain" (479 bytes)

Download attachment "reproduce.pkt" of type "application/octet-stream" (1938 bytes)