Re: [PATCH net-next v2 1/2] ipv6: Honor oif when choosing nexthop for locally generated traffic

[Ido Schimmel <idosch@nvidia.com>]

On Mon, Jun 01, 2026 at 09:52:59AM +0300, Ido Schimmel wrote:
> diff --git a/net/ipv6/route.c b/net/ipv6/route.c
> index b106e5fef9cb..14633fd72288 100644
> --- a/net/ipv6/route.c
> +++ b/net/ipv6/route.c
> @@ -2272,6 +2272,7 @@ struct rt6_info *ip6_pol_route(struct net *net, struct fib6_table *table,
>  {
>  	struct fib6_result res = {};
>  	struct rt6_info *rt = NULL;
> +	bool have_oif_match;
>  	int strict = 0;
>  
>  	WARN_ON_ONCE((flags & RT6_LOOKUP_F_DST_NOREF) &&
> @@ -2288,7 +2289,9 @@ struct rt6_info *ip6_pol_route(struct net *net, struct fib6_table *table,
>  	if (res.f6i == net->ipv6.fib6_null_entry)
>  		goto out;
>  
> -	fib6_select_path(net, &res, fl6, oif, false, skb, strict);
> +	have_oif_match = fl6->flowi6_iif == LOOPBACK_IFINDEX &&
> +			 oif == res.nh->fib_nh_dev->ifindex;
> +	fib6_select_path(net, &res, fl6, oif, have_oif_match, skb, strict);
>  
>  	/*Search through exception table */
>  	rt = rt6_find_cached_rt(&res, &fl6->daddr, &fl6->saddr);

The patch is fine as-is, but Sashiko [1] is correct that there is a
pre-existing issue when the route is using a nexthop group object. I
will prepend a patch for this in the next version and add test cases.

pw-bot: changes-requested

[1]
This is a pre-existing issue, but does this logic leave the regression unfixed
for routes using Nexthop objects?

The fix relies on res.nh containing the best matching path. However, when a
source address is specified, RT6_LOOKUP_F_IFACE is not set. For Nexthop
objects, the lookup in __find_rr_leaf() evaluates paths using
nexthop_for_each_fib6_nh() with the rt6_nh_find_match() callback.

Because the initial score (*mpri) is -1, the first valid (but non-matching)
path will score 0, which causes find_match() to return true. This aborts the
iteration immediately, without evaluating subsequent paths that might be an
exact oif match (which would score 2).

As a result, in ip6_pol_route(), res.nh is assigned an arbitrary path. The
have_oif_match variable evaluates to false, and the code incorrectly falls
back to hash-based selection via nexthop_path_fib6_result() for Nexthop
objects.