Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp481716imm; Wed, 25 Jul 2018 00:14:32 -0700 (PDT) X-Google-Smtp-Source: AAOMgpeZzYpWmAvXK9GcwD4ryYtr5nPLqojJ6nYawHWpU50rPeKONusOb686lPyUeL3uqXR8+3oG X-Received: by 2002:a65:6688:: with SMTP id b8-v6mr19623626pgw.24.1532502872334; Wed, 25 Jul 2018 00:14:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1532502872; cv=none; d=google.com; s=arc-20160816; b=F6BgMJC4m+NdCHekwj/epd8I96o9ZP1ZM2IaIo6Z+obyOUBj2mUpyVRe9xJ7VHbMxe M2BrQnd6LrZbo+bX89NK3v5k76XNUIHdw0aNecCqzuBUHM1cBQFuTs5bWb3STxKLUsy+ 6yen8jofOWkK2X5h5L6qK2WiMcMIVVmRP1ZUx/M7jOTKBNkc3R2T4OyBjVd3tXZkUzI+ IclJyKcw5MJLboR0rbbZMN05NG3QnGarB6GoXf8pYvupIov/hucBYd7KY6GLQ3hcxYIi KGVK6KUVBH7LeaY8/aSFefRT14RQyjLSRb4dGMnvSjdN1QIUC72VPU9GsukWkZ3/tCZl H7BA== 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=oELcsPhtCC62d0+U8//k6tBkPWiN5TMvG/YVJQTbMyQ=; b=eFXC4Ta7VZOFgh/jmY0yIdFRVWU26Y3sTo4Rd043ChkGKrYGL8oAX8hSJIcsYTIioU 9tSZIvvMPT5hRVqc07wCazGe3GMwyvLatOlT74plRrbd5F0rvvk+DVAUN08b7q/W0oas /vSwdqCdc8HoaHLj9Ve1tJx+udCRja4oim32eHakNFHX7WNcAciVbjBhTYQG37L9O85F SzSNOI+Vn+6su43rtMhWE6gOR/lNDUfrHkmAR13/9Zl0Lmth/gRrNhvnoarlPP+7Z4Fz D5TIqY/FiqRG8/0SCpXqd85+KNO1qY2kFwlq2buqwQ6oZwaLsgPm0xciTW2WM5lCdn+f /Khg== 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 s15-v6si12360520pgm.56.2018.07.25.00.14.17; Wed, 25 Jul 2018 00:14:32 -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 S1728652AbeGYIXs (ORCPT + 99 others); Wed, 25 Jul 2018 04:23:48 -0400 Received: from mxhk.zte.com.cn ([63.217.80.70]:38604 "EHLO mxhk.zte.com.cn" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728461AbeGYIXs (ORCPT ); Wed, 25 Jul 2018 04:23:48 -0400 Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Forcepoint Email with ESMTPS id 1EC133B1AAE6C44CBA1C; Wed, 25 Jul 2018 15:13:25 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id w6P7DHso086004; Wed, 25 Jul 2018 15:13:17 +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 2018072515132332-1720483 ; Wed, 25 Jul 2018 15:13:23 +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 v3] ipvs: fix race between ip_vs_conn_new() and ip_vs_del_dest() Date: Wed, 25 Jul 2018 15:23:07 +0800 Message-Id: <1532503387-3800-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 15:13:23, Serialize by Router on notes_smtp/zte_ltd(Release 9.0.1FP7|August 17, 2016) at 2018-07-25 15:13:10, Serialize complete at 2018-07-25 15:13:10 X-MAIL: mse01.zte.com.cn w6P7DHso086004 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 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