Patch "ipv6: Honor specified parameters in fibmatch lookup" has been added to the 4.14-stable tree

This is a note to let you know that I've just added the patch titled

ipv6: Honor specified parameters in fibmatch lookup

to the 4.14-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:
ipv6-honor-specified-parameters-in-fibmatch-lookup.patch
and it can be found in the queue-4.14 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree, please let <[email protected]> know about it.

From: Ido Schimmel <[email protected]>
Date: Wed, 20 Dec 2017 12:28:25 +0200
Subject: ipv6: Honor specified parameters in fibmatch lookup

From: Ido Schimmel <[email protected]>

[ Upstream commit 58acfd714e6b02e8617448b431c2b64a2f1f0792 ]

Currently, parameters such as oif and source address are not taken into account during fibmatch lookup. Example (IPv4 for reference) before patch:

$ ip -4 route show
192.0.2.0/24 dev dummy0 proto kernel scope link src 192.0.2.1
198.51.100.0/24 dev dummy1 proto kernel scope link src 198.51.100.1

$ ip -6 route show
2001:db8:1::/64 dev dummy0 proto kernel metric 256 pref medium
2001:db8:2::/64 dev dummy1 proto kernel metric 256 pref medium
fe80::/64 dev dummy0 proto kernel metric 256 pref medium
fe80::/64 dev dummy1 proto kernel metric 256 pref medium

$ ip -4 route get fibmatch 192.0.2.2 oif dummy0
192.0.2.0/24 dev dummy0 proto kernel scope link src 192.0.2.1
$ ip -4 route get fibmatch 192.0.2.2 oif dummy1
RTNETLINK answers: No route to host

$ ip -6 route get fibmatch 2001:db8:1::2 oif dummy0
2001:db8:1::/64 dev dummy0 proto kernel metric 256 pref medium
$ ip -6 route get fibmatch 2001:db8:1::2 oif dummy1
2001:db8:1::/64 dev dummy0 proto kernel metric 256 pref medium

After:

$ ip -6 route get fibmatch 2001:db8:1::2 oif dummy0
2001:db8:1::/64 dev dummy0 proto kernel metric 256 pref medium
$ ip -6 route get fibmatch 2001:db8:1::2 oif dummy1
RTNETLINK answers: Network is unreachable

The problem stems from the fact that the necessary route lookup flags are not set based on these parameters.

Instead of duplicating the same logic for fibmatch, we can simply resolve the original route from its copy and dump it instead.

---
 net/ipv6/route.c |   19 +++++++++++--------
 1 file changed, 11 insertions(+), 8 deletions(-)

@@ -3700,19 +3700,13 @@ static int inet6_rtm_getroute(struct sk_
 		if (!ipv6_addr_any(&fl6.saddr))
 			flags |= RT6_LOOKUP_F_HAS_SADDR;
 
-		if (!fibmatch)
-			dst = ip6_route_input_lookup(net, dev, &fl6, flags);
-		else
-			dst = ip6_route_lookup(net, &fl6, 0);
+		dst = ip6_route_input_lookup(net, dev, &fl6, flags);
 
 		rcu_read_unlock();
 	} else {
 		fl6.flowi6_oif = oif;
 
-		if (!fibmatch)
-			dst = ip6_route_output(net, NULL, &fl6);
-		else
-			dst = ip6_route_lookup(net, &fl6, 0);
+		dst = ip6_route_output(net, NULL, &fl6);
 	}
 
 

@@ -3729,6 +3723,15 @@ static int inet6_rtm_getroute(struct sk_
 		goto errout;
 	}
 
+	if (fibmatch && rt->dst.from) {
+		struct rt6_info *ort = container_of(rt->dst.from,
+						    struct rt6_info, dst);
+
+		dst_hold(&ort->dst);
+		ip6_rt_put(rt);
+		rt = ort;
+	}
+
 	skb = alloc_skb(NLMSG_GOODSIZE, GFP_KERNEL);
 	if (!skb) {
 		ip6_rt_put(rt);

Patches currently in stable-queue which might be from [email protected] are

queue-4.14/ipv6-honor-specified-parameters-in-fibmatch-lookup.patch queue-4.14/mlxsw-spectrum-disable-mac-learning-for-ovs-port.patch queue-4.14/ipv4-fix-use-after-free-when-flushing-fib-tables.patch