This is a note to let you know that I've just added the patch titled
net: avoid sk_forward_alloc overflows
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
net-avoid-sk_forward_alloc-overflows.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@xxxxxxxxxxxxxxx> know about it.
>From foo@baz Thu Nov 10 16:42:45 CET 2016
From: Eric Dumazet <edumazet@xxxxxxxxxx>
Date: Thu, 15 Sep 2016 08:48:46 -0700
Subject: net: avoid sk_forward_alloc overflows
From: Eric Dumazet <edumazet@xxxxxxxxxx>
[ Upstream commit 20c64d5cd5a2bdcdc8982a06cb05e5e1bd851a3d ]
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@xxxxxxxxxx>
Signed-off-by: David S. Miller <davem@xxxxxxxxxxxxx>
Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
---
include/net/sock.h | 10 ++++++++++
1 file changed, 10 insertions(+)
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -1425,6 +1425,16 @@ static inline void sk_mem_uncharge(struc
if (!sk_has_account(sk))
return;
sk->sk_forward_alloc += size;
+
+ /* Avoid a possible overflow.
+ * TCP send queues can make this happen, if sk_mem_reclaim()
+ * is not called and more than 2 GBytes are released at once.
+ *
+ * If we reach 2 MBytes, reclaim 1 MBytes right now, there is
+ * no need to hold that much forward allocation anyway.
+ */
+ if (unlikely(sk->sk_forward_alloc >= 1 << 21))
+ __sk_mem_reclaim(sk, 1 << 20);
}
static inline void sk_wmem_free_skb(struct sock *sk, struct sk_buff *skb)
Patches currently in stable-queue which might be from edumazet@xxxxxxxxxx are
queue-4.4/ipv4-use-the-right-lock-for-ping_group_range.patch
queue-4.4/ipv4-disable-bh-in-set_ping_group_range.patch
queue-4.4/tcp-fix-a-compile-error-in-dbgundo.patch
queue-4.4/net-avoid-sk_forward_alloc-overflows.patch
queue-4.4/udp-fix-ip_checksum-handling.patch
queue-4.4/netlink-do-not-enter-direct-reclaim-from-netlink_dump.patch
queue-4.4/ipv6-tcp-restore-ip6cb-for-pktoptions-skbs.patch
queue-4.4/tcp-fix-overflow-in-__tcp_retransmit_skb.patch
queue-4.4/packet-on-direct_xmit-limit-tso-and-csum-to-supported-devices.patch
queue-4.4/net-pktgen-remove-rcu-locking-in-pktgen_change_name.patch
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html