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"), fib6nhinit() misclassifies it as a reject route. This is because nexthop objects have no destination prefix (fcdst=::), causing fib6isreject() to match any loopback nexthop. The reject path skips fibnhcommoninit(), leaving nhcpcpurth_output unallocated. If an IPv4 route later references this nexthop, __mkrouteoutput() dereferences NULL nhcpcpurthoutput and panics.

Simplify the check in fib6nhinit() to only match explicit reject routes (RTFREJECT) instead of using fib6isreject(). The loopback promotion heuristic in fib6isreject() is handled separately by ip6routeinfocreate_nh(). After this change, the three cases behave as follows:

1. Explicit reject route ("ip -6 route add unreachable 2001:db8::/64"): RTFREJECT is set, enters reject path, skips fibnhcommoninit(). No behavior change.

2. Implicit loopback reject route ("ip -6 route add 2001:db8::/32 dev lo"): RTFREJECT is not set, takes normal path, fibnhcommoninit() is called. ip6routeinfocreatenh() still promotes it to reject afterward. nhcpcpurth_output is allocated but unused, which is harmless.

3. Standalone nexthop object ("ip -6 nexthop add id 100 dev lo"): RTFREJECT is not set, takes normal path, fibnhcommoninit() is called. nhcpcpurth_output is properly allocated, fixing the crash when IPv4 routes reference this nexthop.