From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.0 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE, SPF_PASS,T_DKIMWL_WL_HIGH,URIBL_BLOCKED,USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id EAD32C282DE for ; Thu, 23 May 2019 19:46:36 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id C50C92133D for ; Thu, 23 May 2019 19:46:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1558640796; bh=01lHJtyrNYUH5+bN6f4WufV/9CfiWbCoRN2sq+yGHVs=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=e3eioPGygKPX94vRO4fMKpikdf+ioLXQj5Wf38qZ4afBVaZGKP6Bs4R/WU32vO/6L ikd+rXkIthCXFMdfMA7dYAWJTI2RpoD0yM63Ev1r+sBl1YU6mbIcO5ktktKucAWZpf 4wpcpdaqlegm7mu/bJc+wNswuH69Q5rxBCzYRBOY= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387395AbfEWTOX (ORCPT ); Thu, 23 May 2019 15:14:23 -0400 Received: from mail.kernel.org ([198.145.29.99]:48334 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388739AbfEWTOU (ORCPT ); Thu, 23 May 2019 15:14:20 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id A509421871; Thu, 23 May 2019 19:14:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1558638860; bh=01lHJtyrNYUH5+bN6f4WufV/9CfiWbCoRN2sq+yGHVs=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=F2TQ97IqHX+6nA1TOPNJ8NB5AIn1pkyuWW/Ka4qCKO05QLPBLcBd97qFVjbZRSu2H PTV2ymf3+Kn6WtvgrP8mGOLINdcVTcM5wOTjgEM/CJQqiLfVAlb2/sCRZ40bimpSMr XSv6FSD7l2mK8mZesRnb8i+5vgmf++e3Z4adQ9qE= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Eric Dumazet , syzbot , Wei Wang , David Ahern , Martin Lau , "David S. Miller" Subject: [PATCH 4.19 002/114] ipv6: prevent possible fib6 leaks Date: Thu, 23 May 2019 21:05:01 +0200 Message-Id: <20190523181731.671123685@linuxfoundation.org> X-Mailer: git-send-email 2.21.0 In-Reply-To: <20190523181731.372074275@linuxfoundation.org> References: <20190523181731.372074275@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Eric Dumazet [ Upstream commit 61fb0d01680771f72cc9d39783fb2c122aaad51e ] At ipv6 route dismantle, fib6_drop_pcpu_from() is responsible for finding all percpu routes and set their ->from pointer to NULL, so that fib6_ref can reach its expected value (1). The problem right now is that other cpus can still catch the route being deleted, since there is no rcu grace period between the route deletion and call to fib6_drop_pcpu_from() This can leak the fib6 and associated resources, since no notifier will take care of removing the last reference(s). I decided to add another boolean (fib6_destroying) instead of reusing/renaming exception_bucket_flushed to ease stable backports, and properly document the memory barriers used to implement this fix. This patch has been co-developped with Wei Wang. Fixes: 93531c674315 ("net/ipv6: separate handling of FIB entries from dst based routes") Signed-off-by: Eric Dumazet Reported-by: syzbot Cc: Wei Wang Cc: David Ahern Cc: Martin Lau Acked-by: Wei Wang Acked-by: Martin KaFai Lau Reviewed-by: David Ahern Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman --- include/net/ip6_fib.h | 3 ++- net/ipv6/ip6_fib.c | 12 +++++++++--- net/ipv6/route.c | 7 +++++++ 3 files changed, 18 insertions(+), 4 deletions(-) --- a/include/net/ip6_fib.h +++ b/include/net/ip6_fib.h @@ -171,7 +171,8 @@ struct fib6_info { dst_nocount:1, dst_nopolicy:1, dst_host:1, - unused:3; + fib6_destroying:1, + unused:2; struct fib6_nh fib6_nh; struct rcu_head rcu; --- a/net/ipv6/ip6_fib.c +++ b/net/ipv6/ip6_fib.c @@ -877,6 +877,12 @@ static void fib6_drop_pcpu_from(struct f { int cpu; + /* Make sure rt6_make_pcpu_route() wont add other percpu routes + * while we are cleaning them here. + */ + f6i->fib6_destroying = 1; + mb(); /* paired with the cmpxchg() in rt6_make_pcpu_route() */ + /* release the reference to this fib entry from * all of its cached pcpu routes */ @@ -900,6 +906,9 @@ static void fib6_purge_rt(struct fib6_in { struct fib6_table *table = rt->fib6_table; + if (rt->rt6i_pcpu) + fib6_drop_pcpu_from(rt, table); + if (atomic_read(&rt->fib6_ref) != 1) { /* This route is used as dummy address holder in some split * nodes. It is not leaked, but it still holds other resources, @@ -921,9 +930,6 @@ static void fib6_purge_rt(struct fib6_in fn = rcu_dereference_protected(fn->parent, lockdep_is_held(&table->tb6_lock)); } - - if (rt->rt6i_pcpu) - fib6_drop_pcpu_from(rt, table); } } --- a/net/ipv6/route.c +++ b/net/ipv6/route.c @@ -1268,6 +1268,13 @@ static struct rt6_info *rt6_make_pcpu_ro prev = cmpxchg(p, NULL, pcpu_rt); BUG_ON(prev); + if (rt->fib6_destroying) { + struct fib6_info *from; + + from = xchg((__force struct fib6_info **)&pcpu_rt->from, NULL); + fib6_info_release(from); + } + return pcpu_rt; }