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.
