Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp1142599imm; Wed, 25 Jul 2018 12:15:10 -0700 (PDT) X-Google-Smtp-Source: AAOMgpdIAfZ4SApCdjvGOkNwhphlhHygAuaReekrvuJCjGz6a84R/TW8mzr+IT83aQ2Nb+y+gcWP X-Received: by 2002:a62:4add:: with SMTP id c90-v6mr23545716pfj.23.1532546109946; Wed, 25 Jul 2018 12:15:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1532546109; cv=none; d=google.com; s=arc-20160816; b=xE2YYsk4MwDAfoajZMFdys6PWlMCDHHIeCSbgEvwUdpZ5b77lL6HR8dXuHEVWFKcRh j/Pons7zlnDydgWb11qT8/zCocE9dVIBsq7hqjBmXoHBo0uNO0EeZFCQ3KRM6EPoQmgs 2x7bJB7t5asn7p1OoV52l9hpPWvE/2NlWtyY1GvAT8pxnwElvgdseoSfpjGXfK5FXuLb vRbX/963i7qkHNED1MXCC7UbZSgFYB8rnDY+j98By6pT/YRAgCsC9yVOQNIEacRlPLtA 07tj+jh0EKSGoOnffXOczYPyMyE1jdC3wSWv1jjhHcVmwKrHiSMjUzSi/AfSvxHmHp0X nf7g== 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=lJxRD495tWJpb7Nn5v73LxzXIuASkm/K4bQRUjjY948=; b=svYFt9FWwsJJoDUnvS+CrK+4LH/GHBIfoG4cEtBH1kzO7gD5KPkLVrfll/JKiHmj54 pqngs2FDnqDnWWgZ5pVmxFv5cbmO3L/YsXpju5tNQ+PqWbo3SGypzdRaBGd3ZVRbVzJP ms6vEljX7B98HUWwTINybgVKAZX/njCYZmtcLbyc+gtlThj0Yc4QmEDdc4aNJL+/lfnH jHtr3JAkWqmuQSKI8ntn1MD0tpotmIKh+ssAqtFDdGagq3iQ5/dHvouCABQPI3yvkCJg treaqODLtC28dHhXaXPBx46ZNToJ+pnnH2jQ8u+l8uv6fkjRmZCHDBSGDqEhPBjAvRPz 26GQ== 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 g9-v6si14120853pgu.294.2018.07.25.12.14.54; Wed, 25 Jul 2018 12:15:09 -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 S1730423AbeGYU0Z (ORCPT + 99 others); Wed, 25 Jul 2018 16:26:25 -0400 Received: from ja.ssi.bg ([178.16.129.10]:47304 "EHLO ja.ssi.bg" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1729202AbeGYU0Z (ORCPT ); Wed, 25 Jul 2018 16:26:25 -0400 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by ja.ssi.bg (8.15.2/8.15.2) with ESMTP id w6PJCmhP003426; Wed, 25 Jul 2018 22:12:50 +0300 Date: Wed, 25 Jul 2018 22:12:48 +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 v3] ipvs: fix race between ip_vs_conn_new() and ip_vs_del_dest() In-Reply-To: <1532503387-3800-1-git-send-email-tan.hu@zte.com.cn> Message-ID: References: <1532503387-3800-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 v3 looks good to me, Acked-by: Julian Anastasov Simon and Pablo, this can be applied to ipvs/nf tree... > --- > v2: fix use-after-free in CONN_ONE_PACKET case suggested by Julian Anastasov > v3: remove trailing whitespace for patch checking > > 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 Regards -- Julian Anastasov