Received: by 10.192.165.156 with SMTP id m28csp1155814imm; Wed, 11 Apr 2018 13:30:12 -0700 (PDT) X-Google-Smtp-Source: AIpwx4+jWfDGtmEUc9Gy0roNm220usw5bhzlKEBrHwn+UMYRI08ieXJr9W/i8l7aDsVQQKt0PTKT X-Received: by 10.98.223.149 with SMTP id d21mr5212631pfl.160.1523478612661; Wed, 11 Apr 2018 13:30:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523478612; cv=none; d=google.com; s=arc-20160816; b=ekAVo+CVWgB5AhB7G86OQdjHU5Af35BimwF3CreKkV2X8VfXfh2ya6y84CvU79krik HtI5vbPL7HiLbyQy6T4rQISzR8kEHXr383sEEfBd9zaifQqF4bXbGtgU4ONIC0fXBK7A TxgIqITajkq72ggqlZTklLENLfmHcB3uUj5B2OSb2kGIlM3L1Fbf3waFU3uAtEIUJHXW eDKqSoa0mTqdFnRVVBNRaAaNcs1Cw4Rt/ggQuQ6wL+ytEo+uCgdxFIFV3a9VMsOu/+ZB PoKDLLMUY5SkwTUY8nKs9qDh5sLW10qxTgrsGDR6OreoZCA83yU+WhdJuNZ4dYVv+5Ry WfMg== 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 :in-reply-to:message-id:date:subject:cc:to:from :arc-authentication-results; bh=QlAMZWzETliGD53Sgy9iP0mZKKvn/y485Nu+/SUkMJI=; b=bg5YXX47TL85TGFox8wa+2BCtCekfuNUmwZrmKe9/K82tE0Q52Rl0xpG/MK2VHeuIR keucfCvvcj43MNIMAUorG1kzmO32K/fy2RDC+GbqqStJWsiECeTxF/7Yednp6nFxZATJ h18tFHYHANFMPC1mb5UvqoW1qeDci4JWbb9fvbW4bKgMdcIdMI/QTUdvn/Uca7S6AE8F S5kHhGb1Dbe8rzyExCD1xAePg0l+IO5hX0uzQu4rLAolRlUOJu9OvzfWXSYIzjHQiV96 DIQcYeQyfopHgvvAlquQ6OFD5xrLSOCz7Lc6YSmUgrGD6gkd3Wbsl8kCIAqukjOljyr6 AmkA== 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 85si1397953pfz.271.2018.04.11.13.29.36; Wed, 11 Apr 2018 13:30:12 -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 S1757082AbeDKUYu (ORCPT + 99 others); Wed, 11 Apr 2018 16:24:50 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:32948 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932791AbeDKSvL (ORCPT ); Wed, 11 Apr 2018 14:51:11 -0400 Received: from localhost (LFbn-1-12247-202.w90-92.abo.wanadoo.fr [90.92.61.202]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id A2929D72; Wed, 11 Apr 2018 18:51:10 +0000 (UTC) From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Donald Sharp , David Ahern , "David S. Miller" Subject: [PATCH 4.4 168/190] net/ipv6: Fix route leaking between VRFs Date: Wed, 11 Apr 2018 20:36:54 +0200 Message-Id: <20180411183602.330118361@linuxfoundation.org> X-Mailer: git-send-email 2.17.0 In-Reply-To: <20180411183550.114495991@linuxfoundation.org> References: <20180411183550.114495991@linuxfoundation.org> User-Agent: quilt/0.65 X-stable: review MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 4.4-stable review patch. If anyone has any objections, please let me know. ------------------ From: David Ahern [ Upstream commit b6cdbc85234b072340b8923e69f49ec293f905dc ] Donald reported that IPv6 route leaking between VRFs is not working. The root cause is the strict argument in the call to rt6_lookup when validating the nexthop spec. ip6_route_check_nh validates the gateway and device (if given) of a route spec. It in turn could call rt6_lookup (e.g., lookup in a given table did not succeed so it falls back to a full lookup) and if so sets the strict argument to 1. That means if the egress device is given, the route lookup needs to return a result with the same device. This strict requirement does not work with VRFs (IPv4 or IPv6) because the oif in the flow struct is overridden with the index of the VRF device to trigger a match on the l3mdev rule and force the lookup to its table. The right long term solution is to add an l3mdev index to the flow struct such that the oif is not overridden. That solution will not backport well, so this patch aims for a simpler solution to relax the strict argument if the route spec device is an l3mdev slave. As done in other places, use the FLOWI_FLAG_SKIP_NH_OIF to know that the RT6_LOOKUP_F_IFACE flag needs to be removed. Fixes: ca254490c8df ("net: Add VRF support to IPv6 stack") Reported-by: Donald Sharp Signed-off-by: David Ahern Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman --- net/ipv6/route.c | 3 +++ 1 file changed, 3 insertions(+) --- a/net/ipv6/route.c +++ b/net/ipv6/route.c @@ -851,6 +851,9 @@ static struct rt6_info *ip6_pol_route_lo struct fib6_node *fn; struct rt6_info *rt; + if (fl6->flowi6_flags & FLOWI_FLAG_SKIP_NH_OIF) + flags &= ~RT6_LOOKUP_F_IFACE; + read_lock_bh(&table->tb6_lock); fn = fib6_lookup(&table->tb6_root, &fl6->daddr, &fl6->saddr); restart: