mirror of
https://github.com/BobTheBlinker/android_kernel_motorola_sm6375.git
synced 2026-10-29 11:11:45 -04:00
ipv6: fib6_select_path can not use out path for nexthop objects
[ Upstream commit 34fe5a1cf95c3f114068fc16d919c9cf4b00e428 ]
Brian reported a crash in IPv6 code when using rpfilter with a setup
running FRR and external nexthop objects. The root cause of the crash
is fib6_select_path setting fib6_nh in the result to NULL because of
an improper check for nexthop objects.
More specifically, rpfilter invokes ip6_route_lookup with flowi6_oif
set causing fib6_select_path to be called with have_oif_match set.
fib6_select_path has early check on have_oif_match and jumps to the
out label which presumes a builtin fib6_nh. This path is invalid for
nexthop objects; for external nexthops fib6_select_path needs to just
return if the fib6_nh has already been set in the result otherwise it
returns after the call to nexthop_path_fib6_result. Update the check
on have_oif_match to not bail on external nexthops.
Update selftests for this problem.
Fixes: f88d8ea67f ("ipv6: Plumb support for nexthop object in a fib6_info")
Reported-by: Brian Rak <[email protected]>
Signed-off-by: David Ahern <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
This commit is contained in:
parent
1418b60e99
commit
75270f8196
2 changed files with 17 additions and 1 deletions
|
|
@ -431,9 +431,12 @@ void fib6_select_path(const struct net *net, struct fib6_result *res,
|
|||
struct fib6_info *sibling, *next_sibling;
|
||||
struct fib6_info *match = res->f6i;
|
||||
|
||||
if ((!match->fib6_nsiblings && !match->nh) || have_oif_match)
|
||||
if (!match->nh && (!match->fib6_nsiblings || have_oif_match))
|
||||
goto out;
|
||||
|
||||
if (match->nh && have_oif_match && res->nh)
|
||||
return;
|
||||
|
||||
/* We might have already computed the hash for ICMPv6 errors. In such
|
||||
* case it will always be non-zero. Otherwise now is the time to do it.
|
||||
*/
|
||||
|
|
|
|||
Loading…
Reference in a new issue