Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp299740imm; Tue, 24 Jul 2018 19:41:01 -0700 (PDT) X-Google-Smtp-Source: AAOMgpdtrCyaQQfJCsSEV9CXNuDtj5FHUbLxbJlENOmF8oUq1zNvdn2lcpAD6hy9qor/ntwFyYGN X-Received: by 2002:a65:5a8a:: with SMTP id c10-v6mr17967594pgt.389.1532486460991; Tue, 24 Jul 2018 19:41:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1532486460; cv=none; d=google.com; s=arc-20160816; b=xjzR5gxRR36YghkfhqbYLpPsCnlo+Jrlt6VPdfB3kQCW2+l54qyihZY3UgCO4750zf z7RXxi+4nfm24FBf8L9CpO3n2NdfNdsOFH8ro9Liavbwu5dMiPj/WYqU7pHufEtpa7Pd avh6eXIDcZmpgErzCpuSQHfDDY8sdR9L/s1kKvgmNdts+e72/1IhhaLAxCyoRa9hJ2KJ WAvEErhjlE4a1CsiaNmuw6bxutTNHiq6c+T46T9CU8kjSrQEbq6cLpP2EWg309Q2+RWg ERzKjhMCBjKx0E0T3pH5BHWuy3MB+QyFiq5X3FPM2LQt2jVXnaGmqpvPWJvOxy1cwtaC 3fzw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from :arc-authentication-results; bh=gPCgAaibjsLm35ErIlbVfF/n2Wl6m/2erucaVFjK2C4=; b=R1s4cec2Emf2yALz/1f1cISiJtMN7e6GwHKAT+lbANB4DGSLqsH/SDX3fLvGrSwVZu 44/E9+wZy+qKQ3NAWXikRO6ZDLuWWewYhZcmrDj4UjFNJbG6NfwR2aUCTIZHPrqoJDuY 6O1eMgEU7nc2MG4gJdzckUnH4qFPh4puDk37T8bTiN9tzdsCcVHSwopliIgwrzD8BIEv MRtMRSJFZzUJMct2CeeX1QTubPRJtVwIOxjqRHFeC/kFtLUqmrLgxikcoj53eY7EyEon G84AK7dYnpn+GFjlGPaEBxWiA46HTrkGRVe8AjZNhj0+9edDG/V3ZLLudWIVJ3UefePE MzLA== 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 v37-v6si12115125plg.486.2018.07.24.19.40.46; Tue, 24 Jul 2018 19:41:00 -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 S2388523AbeGYDtY (ORCPT + 99 others); Tue, 24 Jul 2018 23:49:24 -0400 Received: from mxhk.zte.com.cn ([63.217.80.70]:60414 "EHLO mxhk.zte.com.cn" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727353AbeGYDtY (ORCPT ); Tue, 24 Jul 2018 23:49:24 -0400 Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Forcepoint Email with ESMTPS id 5D9FAAF97150380B47A0; Wed, 25 Jul 2018 10:39:54 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id w6P2dmGn074604; Wed, 25 Jul 2018 10:39:48 +0800 (GMT-8) (envelope-from tan.hu@zte.com.cn) Received: from localhost.localdomain ([10.75.9.60]) by szsmtp06.zte.com.cn (Lotus Domino Release 8.5.3FP6) with ESMTP id 2018072510395327-1663834 ; Wed, 25 Jul 2018 10:39:53 +0800 From: Tan Hu To: wensong@linux-vs.org, horms@verge.net.au, ja@ssi.bg, pablo@netfilter.org, kadlec@blackhole.kfki.hu, fw@strlen.de, davem@davemloft.net Cc: netdev@vger.kernel.org, lvs-devel@vger.kernel.org, netfilter-devel@vger.kernel.org, coreteam@netfilter.org, linux-kernel@vger.kernel.org, zhong.weidong@zte.com.cn, jiang.biao2@zte.com.cn Subject: [PATCH v2] ipvs: fix race between ip_vs_conn_new() and ip_vs_del_dest() Date: Wed, 25 Jul 2018 10:49:40 +0800 Message-Id: <1532486980-17844-1-git-send-email-tan.hu@zte.com.cn> X-Mailer: git-send-email 1.8.3.1 X-MIMETrack: Itemize by SMTP Server on SZSMTP06/server/zte_ltd(Release 8.5.3FP6|November 21, 2013) at 2018-07-25 10:39:53, Serialize by Router on notes_smtp/zte_ltd(Release 9.0.1FP7|August 17, 2016) at 2018-07-25 10:39:41, Serialize complete at 2018-07-25 10:39:41 X-MAIL: mse01.zte.com.cn w6P2dmGn074604 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org We came across infinite loop in ipvs when using ipvs in docker env. When ipvs receives new packets and cannot find an ipvs connection, it will create a new connection, then if the dest is unavailable (i.e. IP_VS_DEST_F_AVAILABLE), the packet will be dropped sliently. But if the dropped packet is the first packet of this connection, the connection control timer never has a chance to start and the ipvs connection cannot be released. This will lead to memory leak, or infinite loop in cleanup_net() when net namespace is released like this: ip_vs_conn_net_cleanup at ffffffffa0a9f31a [ip_vs] __ip_vs_cleanup at ffffffffa0a9f60a [ip_vs] ops_exit_list at ffffffff81567a49 cleanup_net at ffffffff81568b40 process_one_work at ffffffff810a851b worker_thread at ffffffff810a9356 kthread at ffffffff810b0b6f ret_from_fork at ffffffff81697a18 race condition: CPU1 CPU2 ip_vs_in() ip_vs_conn_new() ip_vs_del_dest() __ip_vs_unlink_dest() ~IP_VS_DEST_F_AVAILABLE cp->dest && !IP_VS_DEST_F_AVAILABLE __ip_vs_conn_put ... cleanup_net ---> infinite looping Fix this by checking whether the timer already started. Signed-off-by: Tan Hu Reviewed-by: Jiang Biao --- v2: fix use-after-free in CONN_ONE_PACKET case suggested by Julian Anastasov net/netfilter/ipvs/ip_vs_core.c | 15 +++++++++++---- 1 file changed, 11 insertions(+), 4 deletions(-) diff --git a/net/netfilter/ipvs/ip_vs_core.c b/net/netfilter/ipvs/ip_vs_core.c index 0679dd1..a17104f 100644 --- a/net/netfilter/ipvs/ip_vs_core.c +++ b/net/netfilter/ipvs/ip_vs_core.c @@ -1972,13 +1972,20 @@ static int ip_vs_in_icmp_v6(struct netns_ipvs *ipvs, struct sk_buff *skb, if (cp->dest && !(cp->dest->flags & IP_VS_DEST_F_AVAILABLE)) { /* the destination server is not available */ - if (sysctl_expire_nodest_conn(ipvs)) { + __u32 flags = cp->flags; + + /* when timer already started, silently drop the packet.*/ + if (timer_pending(&cp->timer)) + __ip_vs_conn_put(cp); + else + ip_vs_conn_put(cp); + + if (sysctl_expire_nodest_conn(ipvs) && + !(flags & IP_VS_CONN_F_ONE_PACKET)) { /* try to expire the connection immediately */ ip_vs_conn_expire_now(cp); } - /* don't restart its timer, and silently - drop the packet. */ - __ip_vs_conn_put(cp); + return NF_DROP; } -- 1.8.3.1