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: <20170119.114103.1784185156530691440.davem@davemloft.net>
Date:   Thu, 19 Jan 2017 11:41:03 -0500 (EST)
From:   David Miller <davem@...emloft.net>
To:     alexey.kodanev@...cle.com
Cc:     netdev@...r.kernel.org, eric.dumazet@...il.com, ycheng@...gle.com,
        ncardwell@...gle.com
Subject: Re: [PATCH] tcp: initialize max window for a new fastopen socket

From: Alexey Kodanev <alexey.kodanev@...cle.com>
Date: Thu, 19 Jan 2017 16:36:39 +0300

> Found that if we run LTP netstress test with large MSS (65K),
> the first attempt from server to send data comparable to this
> MSS on fastopen connection will be delayed by the probe timer.
> 
> Here is an example:
> 
>      < S  seq 0:0 win 43690 options [mss 65495 wscale 7 tfo cookie] length 32
>      > S. seq 0:0 ack 1 win 43690 options [mss 65495 wscale 7] length 0
>      < .  ack 1 win 342 length 0
> 
> Inside tcp_sendmsg(), tcp_send_mss() returns max MSS in 'mss_now',
> as well as in 'size_goal'. This results the segment not queued for
> transmition until all the data copied from user buffer. Then, inside
> __tcp_push_pending_frames(), it breaks on send window test and
> continues with the check probe timer.
> 
> Fragmentation occurs in tcp_write_wakeup()...
> 
> +0.2 > P. seq 1:43777 ack 1 win 342 length 43776
>      < .  ack 43777, win 1365 length 0
>      > P. seq 43777:65001 ack 1 win 342 options [...] length 21224
>      ...
> 
> This also contradicts with the fact that we should bound to the half
> of the window if it is large.
> 
> Fix this flaw by correctly initializing max_window. Before that, it
> could have large values that affect further calculations of 'size_goal'.
> 
> Fixes: 168a8f58059a ("tcp: TCP Fast Open Server - main code path")
> Signed-off-by: Alexey Kodanev <alexey.kodanev@...cle.com>

Applied and queued up for -stable, thanks.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ