summaryrefslogtreecommitdiffstats
path: root/REPORTING-BUGS
diff options
context:
space:
mode:
authorEric Dumazet <edumazet@google.com>2016-09-15 08:48:46 -0700
committerDavid S. Miller <davem@davemloft.net>2016-09-17 09:59:31 -0400
commit20c64d5cd5a2bdcdc8982a06cb05e5e1bd851a3d (patch)
treefa00e073091d3ac7f3f11cc89ff396c510573e0c /REPORTING-BUGS
parentffb4d6c8508657824bcef68a36b2a0f9d8c09d10 (diff)
downloadlinux-20c64d5cd5a2bdcdc8982a06cb05e5e1bd851a3d.tar.bz2
net: avoid sk_forward_alloc overflows
A malicious TCP receiver, sending SACK, can force the sender to split skbs in write queue and increase its memory usage. Then, when socket is closed and its write queue purged, we might overflow sk_forward_alloc (It becomes negative) sk_mem_reclaim() does nothing in this case, and more than 2GB are leaked from TCP perspective (tcp_memory_allocated is not changed) Then warnings trigger from inet_sock_destruct() and sk_stream_kill_queues() seeing a not zero sk_forward_alloc All TCP stack can be stuck because TCP is under memory pressure. A simple fix is to preemptively reclaim from sk_mem_uncharge(). This makes sure a socket wont have more than 2 MB forward allocated, after burst and idle period. Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'REPORTING-BUGS')
0 files changed, 0 insertions, 0 deletions