Re: [PATCH net v2 1/2] net: ipv6: fix panic when IPv4 route references loopback IPv6 nexthop

[Ido Schimmel <idosch@nvidia.com>]

On Mon, Mar 02, 2026 at 09:07:34AM +0000, Jiayuan Chen wrote:
> Thanks, this is indeed the simplest fix.
> 
> Let me walk through each case to confirm my understanding:
> 
> Case 1: Explicit reject route (with RTF_REJECT)
> ip -6 route add unreachable 2001:db8:1::/64
> 
> cfg->fc_flags has RTF_REJECT before entering fib6_nh_init(), so the reject path is taken.
> fib_nh_common_init() is skipped, nhc_pcpu_rth_output is not allocated. This is fine since reject
> routes never need it.
> 
> 
> Case 2: Loopback implicit reject route (without RTF_REJECT)
> ip -6 route add 2001:db8::/32 dev lo
> 
> cfg->fc_flags does not have RTF_REJECT, so fib6_nh_init() takes the normal path and
> fib_nh_common_init() allocates nhc_pcpu_rth_output. Later, ip6_route_info_create() calls
> fib6_is_reject() and marks the route as RTF_REJECT.
> The allocated nhc_pcpu_rth_output is unused but harmless.
> 
> 
> Case 3: Standalone nexthop object (our bug scenario)
> ip -6 nexthop add id 100 dev lo
> 
> ip route add 172.20.20.0/24 nhid 100
> cfg->fc_flags does not have RTF_REJECT (nexthop objects never carry route attributes),
> so fib6_nh_init() takes the normal path and fib_nh_common_init() allocates nhc_pcpu_rth_output.
> This fixes the crash when an IPv4 route later references this nexthop.

Yes, that's my understanding as well.

FWIW, I ran the various FIB selftests with the diff that I suggested and
didn't see any issues.