diff options
author | Eric Dumazet <edumazet@google.com> | 2015-05-14 14:26:56 -0700 |
---|---|---|
committer | David S. Miller <davem@davemloft.net> | 2015-05-14 22:32:17 -0400 |
commit | 264ea103a7473f51aced838e68ed384ea2c759f5 (patch) | |
tree | 0f8366835d004fb0ee387d876f6c4b301a0ff89e /lib/test_bpf.c | |
parent | c24a59649f3c8f4f78adc2d0e31423fa883b012b (diff) | |
download | linux-264ea103a7473f51aced838e68ed384ea2c759f5.tar.gz linux-264ea103a7473f51aced838e68ed384ea2c759f5.tar.bz2 linux-264ea103a7473f51aced838e68ed384ea2c759f5.zip |
tcp: syncookies: extend validity range
Now we allow storing more request socks per listener, we might
hit syncookie mode less often and hit following bug in our stack :
When we send a burst of syncookies, then exit this mode,
tcp_synq_no_recent_overflow() can return false if the ACK packets coming
from clients are coming three seconds after the end of syncookie
episode.
This is a way too strong requirement and conflicts with rest of
syncookie code which allows ACK to be aged up to 2 minutes.
Perfectly valid ACK packets are dropped just because clients might be
in a crowded wifi environment or on another planet.
So let's fix this, and also change tcp_synq_overflow() to not
dirty a cache line for every syncookie we send, as we are under attack.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Acked-by: Florian Westphal <fw@strlen.de>
Acked-by: Yuchung Cheng <ycheng@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'lib/test_bpf.c')
0 files changed, 0 insertions, 0 deletions