CVE-2026-23300

In the Linux kernel, the following vulnerability has been resolved:

net: ipv6: fix panic when IPv4 route references loopback IPv6 nexthop

When a standalone IPv6 nexthop object is created with a loopback device

(e.g., "ip -6 nexthop add id 100 dev lo"), fib6_nh_init() misclassifies

it as a reject route. This is because nexthop objects have no destination

prefix (fc_dst=::), causing fib6_is_reject() to match any loopback

nexthop. The reject path skips fib_nh_common_init(), leaving

nhc_pcpu_rth_output unallocated. If an IPv4 route later references this

nexthop, __mkroute_output() dereferences NULL nhc_pcpu_rth_output and

panics.

Simplify the check in fib6_nh_init() to only match explicit reject

routes (RTF_REJECT) instead of using fib6_is_reject(). The loopback

promotion heuristic in fib6_is_reject() is handled separately by

ip6_route_info_create_nh(). After this change, the three cases behave

as follows:

1. Explicit reject route ("ip -6 route add unreachable 2001:db8::/64"):

RTF_REJECT is set, enters reject path, skips fib_nh_common_init().

No behavior change.

2. Implicit loopback reject route ("ip -6 route add 2001:db8::/32 dev lo"):

RTF_REJECT is not set, takes normal path, fib_nh_common_init() is

called. ip6_route_info_create_nh() still promotes it to reject

afterward. nhc_pcpu_rth_output is allocated but unused, which is

harmless.

3. Standalone nexthop object ("ip -6 nexthop add id 100 dev lo"):

RTF_REJECT is not set, takes normal path, fib_nh_common_init() is

called. nhc_pcpu_rth_output is properly allocated, fixing the crash

when IPv4 routes reference this nexthop.