From: <gregkh@linuxfoundation.org>
To: dsahern@gmail.com, davem@davemloft.net,
gregkh@linuxfoundation.org, sharpd@cumulusnetworks.com
Cc: <stable@vger.kernel.org>, <stable-commits@vger.kernel.org>
Subject: Patch "net/ipv6: Fix route leaking between VRFs" has been added to the 4.15-stable tree
Date: Tue, 10 Apr 2018 23:21:40 +0200 [thread overview]
Message-ID: <15233953007955@kroah.com> (raw)
This is a note to let you know that I've just added the patch titled
net/ipv6: Fix route leaking between VRFs
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
net-ipv6-fix-route-leaking-between-vrfs.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From foo@baz Tue Apr 10 23:19:36 CEST 2018
From: David Ahern <dsahern@gmail.com>
Date: Thu, 29 Mar 2018 17:44:57 -0700
Subject: net/ipv6: Fix route leaking between VRFs
From: David Ahern <dsahern@gmail.com>
[ 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 <sharpd@cumulusnetworks.com>
Signed-off-by: David Ahern <dsahern@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/ipv6/route.c | 3 +++
1 file changed, 3 insertions(+)
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -922,6 +922,9 @@ static struct rt6_info *ip6_pol_route_lo
struct rt6_info *rt, *rt_cache;
struct fib6_node *fn;
+ if (fl6->flowi6_flags & FLOWI_FLAG_SKIP_NH_OIF)
+ flags &= ~RT6_LOOKUP_F_IFACE;
+
rcu_read_lock();
fn = fib6_lookup(&table->tb6_root, &fl6->daddr, &fl6->saddr);
restart:
Patches currently in stable-queue which might be from dsahern@gmail.com are
queue-4.15/perf-evsel-fix-swap-for-samples-with-raw-data.patch
queue-4.15/perf-tools-fix-copyfile_offset-update-of-output-offset.patch
queue-4.15/net-ipv6-fix-route-leaking-between-vrfs.patch
queue-4.15/vrf-fix-use-after-free-and-double-free-in-vrf_finish_output.patch
reply other threads:[~2018-04-10 21:23 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=15233953007955@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=davem@davemloft.net \
--cc=dsahern@gmail.com \
--cc=sharpd@cumulusnetworks.com \
--cc=stable-commits@vger.kernel.org \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.