Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp477102imm; Fri, 14 Sep 2018 01:15:28 -0700 (PDT) X-Google-Smtp-Source: ANB0VdZdXUpFQtxjkAOGoUzhtok9C1WN2bp8/eHgT2dU6eQb4x8tyvFI3zbRDapMDrEbdx0Eg+iz X-Received: by 2002:aa7:82c3:: with SMTP id f3-v6mr11445389pfn.136.1536912928517; Fri, 14 Sep 2018 01:15:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1536912928; cv=none; d=google.com; s=arc-20160816; b=OQmvyJhi9uPF3cQLl3uxs8TeoOfvaI7ne46Qfa9mMAUouPSeNUaq/MuXLbkLOi6wAl uMtqEnxcIEPbaxsxjCFoUjDqZVZS+Tb7cA3mfrJsp0ENwaVJbJeMAOdXitGoF2B5gd7T ESTY26iYW2Rnhr61m9nzTmYIE5wRyUdJtpRs46vuhYM1+7oiehGu8uuORTLAQPzbKCDi X24V+JNL+kAQ769IXZJy5KqMDGmYmdQHurLzybm63gpRV7vi84zVBXJSRRoPjfkc6g6A 8sprPe220kDI5lHNeY9y6VOEaYlAj9GklJY9fW4jk0e0WtUcMXIl3fakltdlQwHkhmO1 sXDQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:references:in-reply-to :message-id:date:subject:to:from; bh=Rb9AfwTNfyGI6OtioL98CD22/Jy4e34n4OvrYa+XNzo=; b=OAjIX8TVO5EbmUdbxPr8qbdpQ7OCGIVmBFP5ofikVFy3YVOMylCU7xOlZz+BIksQmV L7tfamNkYwa8z18toKeZlngR4YgnFGedcVejWCjW5ty6QDlFM6WvP7G97VaimygNbk+W cQjhUh633EfAStgSb/cDEZ44JuboK2rgjP5yIEBHSfzViK8D92zYnRsB7uowmNM9cyta +ijksAosHRQi6SAhZ4i0i564VqKk/u+MbiEZh7RPMih48lTcNkW+H6XRkMc79DklgT6G fj+n4VjeKAW4NmFI0QW7s9/K2IONqTLfi9BVMKXtnW9nW8McW4MgQaFSMtKYrTyuviCh jvBQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id e14-v6si6508264pgj.413.2018.09.14.01.15.13; Fri, 14 Sep 2018 01:15:28 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728241AbeINN2P (ORCPT + 99 others); Fri, 14 Sep 2018 09:28:15 -0400 Received: from szxga04-in.huawei.com ([45.249.212.190]:12129 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726883AbeINN1y (ORCPT ); Fri, 14 Sep 2018 09:27:54 -0400 Received: from DGGEMS410-HUB.china.huawei.com (unknown [172.30.72.58]) by Forcepoint Email with ESMTP id 9CE095FEF1D92; Fri, 14 Sep 2018 16:14:29 +0800 (CST) Received: from localhost.localdomain.localdomain (10.175.113.25) by DGGEMS410-HUB.china.huawei.com (10.3.19.210) with Microsoft SMTP Server id 14.3.399.0; Fri, 14 Sep 2018 16:14:24 +0800 From: Mao Wenan To: , , , , , , , Subject: [PATCH stable 4.4 V2 4/6] tcp: free batches of packets in tcp_prune_ofo_queue() Date: Fri, 14 Sep 2018 16:24:08 +0800 Message-ID: <1536913450-12380-5-git-send-email-maowenan@huawei.com> X-Mailer: git-send-email 1.8.3.1 In-Reply-To: <1536913450-12380-1-git-send-email-maowenan@huawei.com> References: <1536913450-12380-1-git-send-email-maowenan@huawei.com> MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [10.175.113.25] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Eric Dumazet [ Upstream commit 72cd43ba64fc172a443410ce01645895850844c8 ] Juha-Matti Tilli reported that malicious peers could inject tiny packets in out_of_order_queue, forcing very expensive calls to tcp_collapse_ofo_queue() and tcp_prune_ofo_queue() for every incoming packet. out_of_order_queue rb-tree can contain thousands of nodes, iterating over all of them is not nice. Before linux-4.9, we would have pruned all packets in ofo_queue in one go, every XXXX packets. XXXX depends on sk_rcvbuf and skbs truesize, but is about 7000 packets with tcp_rmem[2] default of 6 MB. Since we plan to increase tcp_rmem[2] in the future to cope with modern BDP, can not revert to the old behavior, without great pain. Strategy taken in this patch is to purge ~12.5 % of the queue capacity. Fixes: 36a6503fedda ("tcp: refine tcp_prune_ofo_queue() to not drop all packets") Signed-off-by: Eric Dumazet Reported-by: Juha-Matti Tilli Acked-by: Yuchung Cheng Acked-by: Soheil Hassas Yeganeh Signed-off-by: David S. Miller Signed-off-by: Mao Wenan --- net/ipv4/tcp_input.c | 16 +++++++++++----- 1 file changed, 11 insertions(+), 5 deletions(-) diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c index 4cc0a53..4739a93 100644 --- a/net/ipv4/tcp_input.c +++ b/net/ipv4/tcp_input.c @@ -4899,27 +4899,33 @@ new_range: /* * Purge the out-of-order queue. + * Drop at least 12.5 % of sk_rcvbuf to avoid malicious attacks. * Return true if queue was pruned. */ static bool tcp_prune_ofo_queue(struct sock *sk) { struct tcp_sock *tp = tcp_sk(sk); struct rb_node *node, *prev; + int goal; if (RB_EMPTY_ROOT(&tp->out_of_order_queue)) return false; NET_INC_STATS_BH(sock_net(sk), LINUX_MIB_OFOPRUNED); - + goal = sk->sk_rcvbuf >> 3; node = &tp->ooo_last_skb->rbnode; do { prev = rb_prev(node); rb_erase(node, &tp->out_of_order_queue); + goal -= rb_to_skb(node)->truesize; __kfree_skb(rb_to_skb(node)); - sk_mem_reclaim(sk); - if (atomic_read(&sk->sk_rmem_alloc) <= sk->sk_rcvbuf && - !tcp_under_memory_pressure(sk)) - break; + if (!prev || goal <= 0) { + sk_mem_reclaim(sk); + if (atomic_read(&sk->sk_rmem_alloc) <= sk->sk_rcvbuf && + !tcp_under_memory_pressure(sk)) + break; + goal = sk->sk_rcvbuf >> 3; + } node = prev; } while (node); -- 1.8.3.1