netdev - Re: [PATCH v2 net] ipv6: fib6_select_path can not use out path for nexthop objects

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <20200706.132449.437332703151179232.davem@davemloft.net>
Date:   Mon, 06 Jul 2020 13:24:49 -0700 (PDT)
From:   David Miller <davem@...emloft.net>
To:     dsahern@...nel.org
Cc:     netdev@...r.kernel.org, kuba@...nel.org, brak@...opa.com
Subject: Re: [PATCH v2 net] ipv6: fib6_select_path can not use out path for
 nexthop objects

From: David Ahern <dsahern@...nel.org>
Date: Mon,  6 Jul 2020 11:45:07 -0600

> 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: f88d8ea67fbd ("ipv6: Plumb support for nexthop object in a fib6_info")
> Reported-by: Brian Rak <brak@...opa.com>
> Signed-off-by: David Ahern <dsahern@...nel.org>
> ---
> v2
> - for multipath nexthops path may already be set; do not want to
>   overwrite that selection based on hash

Applied and queued up for -stable, thanks David.