CVE-2026-53012: nexthop: fix IPv6 route referencing IPv4 nexthop
In the Linux kernel, the following vulnerability has been resolved:
nexthop: fix IPv6 route referencing IPv4 nexthop
syzbot reported a panic [1] [2].
When an IPv6 nexthop is replaced with an IPv4 nexthop, the hasv4 flag of all groups containing this nexthop is not updated. This is because nhgroupv4update is only called when replacing AFINET to AFINET6, but the reverse direction (AFINET6 to AFINET) is missed.
This allows a stale hasv4=false to bypass fib6checknexthop, causing IPv6 routes to be attached to groups that effectively contain only AFINET members. Subsequent route lookups then call nexthopfib6nh() which returns NULL for the AFINET member, leading to a NULL pointer dereference.
Fix by calling nhgroupv4update whenever the family changes, not just AFINET to AFINET6.
Reproducer: # AFINET6 blackhole ip -6 nexthop add id 1 blackhole # group with hasv4=false ip nexthop add id 100 group 1 # replace with AFINET (no -6), hasv4 stays false ip nexthop replace id 1 blackhole # pass stale hasv4 check ip -6 route add 2001:db8::/64 nhid 100 # panic ping -6 2001:db8::1
[1] https://syzkaller.appspot.com/bug?id=e17283eb2f8dcf3dd9b47fe6f67a95f71faadad0 [2] https://syzkaller.appspot.com/bug?id=8699b6ae54c9f35837d925686208402949e12ef3
Affected Software
Remediation
Event History
Frequently Asked Questions
What conditions are required to trigger the crash?
An attacker or local user needs privileges to create and replace nexthop objects and add IPv6 routes. The triggering sequence replaces an IPv6 nexthop in a group with an IPv4 nexthop, attaches an IPv6 route to that group, and performs an IPv6 route lookup.
Is this remotely exploitable?
The supplied vector is AV:L and PR:L, indicating local access and low privileges are required. No user interaction is required.
What is the practical impact?
A subsequent IPv6 route lookup can dereference a NULL pointer and panic the kernel, causing a denial of service. The provided data does not indicate confidentiality or integrity impact.
How can I identify an affected configuration?
Look for nexthop groups that were created with IPv6 members and later had a member replaced by an IPv4 nexthop. If the group retained a stale has_v4=false state and IPv6 routes were attached through it, IPv6 lookups may trigger the panic.
What should be done if patching cannot happen immediately?
Restrict untrusted local users from managing nexthops and routes, particularly replacing IPv6 nexthops with IPv4 nexthops in existing groups. Avoid attaching IPv6 routes to groups after such replacements until the patch is applied.