Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp423867imm; Tue, 24 Jul 2018 22:55:52 -0700 (PDT) X-Google-Smtp-Source: AAOMgpdY1YHaDKfB2nD4x4HspTpm/lGlm68/uY5hv9dtsfzbfJ9M5V1KW3LLiauvsDE2lx9yhCGm X-Received: by 2002:a62:fb05:: with SMTP id x5-v6mr20835247pfm.210.1532498152804; Tue, 24 Jul 2018 22:55:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1532498152; cv=none; d=google.com; s=arc-20160816; b=Q+aA5G7fqYgb3n27WZXDxPNz/tSqUKcEEP9IHeMzlrnzgx3l8K1OKmO0600ayyFY1i obxpQF8LrVa3yLz9+Lx6OxeeSAkGfq/JetFoO4s4nGKZZc5f4d5sTYkQ/4iXGfCPvMIc dx54v8WXNXW4g4diG7Y4ow3epMYxugoIwFeshBvNJNvWVL0uM6W348jUcnb+IBOyDt61 Vfn0K2ZDg/RThxs2CqfxXoPVEEIpIDBw4OfHZxA04kzoD5il6ae+CKpJMYRqCTFQsbBv HP+kG9AOOFFSn0TO2IrBRM1/cUlIYEZjM+p+mBW27GrUKNHVAOja3knzFDIkNfa65K7C 4DvQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date :arc-authentication-results; bh=75VXmki/2C+37tsZTK0zDqDiEgwNlgfkfDeynqNUm8g=; b=oEKx7SLZN7pmx55QMLMlxr5SMDHUIuQGBD3lhBSWzdtuPIeobLUHQeXyKCne7l2YjF WeB/cym/oK7txHUj6EDig1LCBO23deFVRtBHNXc9kiz29WAhnZnAjGwAzwtZiiYkOPSM xlYwWK7DKxHGWBg9AVBaYTEwWgNKMwylHgUEiBLU4q4oIg3AmstX1LpeD1gXxpjUI0NR w/c6hw7hnizXTTMTkiclztoY1TxAx+wZbS5wYiXHsyeFOnln1JPNsdXoU3MP2iMoHlMm e+6EYVGnG9f0XRupHEGL9G3XCoDQMUPiOm7NUS76CObZp8o5H8fsFa+U6gKDIKPHOeSg yllw== 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 w10-v6si11842595ply.482.2018.07.24.22.55.37; Tue, 24 Jul 2018 22:55:52 -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 S1728570AbeGYHEP (ORCPT + 99 others); Wed, 25 Jul 2018 03:04:15 -0400 Received: from ja.ssi.bg ([178.16.129.10]:60856 "EHLO ja.ssi.bg" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1727985AbeGYHEO (ORCPT ); Wed, 25 Jul 2018 03:04:14 -0400 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by ja.ssi.bg (8.15.2/8.15.2) with ESMTP id w6P5rhSV003122; Wed, 25 Jul 2018 08:53:43 +0300 Date: Wed, 25 Jul 2018 08:53:43 +0300 (EEST) From: Julian Anastasov To: Tan Hu cc: wensong@linux-vs.org, horms@verge.net.au, pablo@netfilter.org, kadlec@blackhole.kfki.hu, fw@strlen.de, davem@davemloft.net, 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: Re: [PATCH v2] ipvs: fix race between ip_vs_conn_new() and ip_vs_del_dest() In-Reply-To: <1532486980-17844-1-git-send-email-tan.hu@zte.com.cn> Message-ID: References: <1532486980-17844-1-git-send-email-tan.hu@zte.com.cn> User-Agent: Alpine 2.20 (LFD 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello, On Wed, 25 Jul 2018, Tan Hu wrote: > 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; Ops, now scripts/checkpatch.pl --strict /tmp/file.patch is complaining about extra trailing space in above line. You can also remove the empty line above the new code... Regards -- Julian Anastasov