blob: 6e4923b810d0b602c20a4f3222f7dfccfc633ca4 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
|
Description: TCP SYN handling serialised by listening socket lock
References:
https://cxsecurity.com/issue/WLB-2017020112
https://githubengineering.com/syn-flood-mitigation-with-synsanity/
Notes:
bwh> This is described as a defect in SYN cookies, but it's really a
bwh> scaling limitation that was never intended to be addressed by
bwh> cookies. The listening socket's lock is held while processing
bwh> SYN packets, so an attacker only needs to keep 1 CPU busy to
bwh> achieve DoS. While the upstream fix looks simple, I think it
bwh> depends on a number of earlier commits.
Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1422081
upstream: released (4.4-rc1) [e994b2f0fb9229aeff5eea9541320bd7b2ca8714]
4.9-upstream-stable: N/A "Fixed before branch point"
3.16-upstream-stable: ignored "Known perfomance limitation"
3.2-upstream-stable: ignored "Known perfomance limitation"
sid: released (4.4~rc4-1~exp1)
3.16-jessie-security: ignored "Known perfomance limitation"
3.2-wheezy-security: ignored "Known perfomance limitation"
|
