CVE-2026-53012

What it actually does

This Linux kernel flaw is a local denial-of-service condition in the nexthop routing subsystem. When a nexthop used by a group is changed from IPv6 to IPv4, the kernel can fail to update the group’s internal IPv4/IPv6 state. That stale state can allow an IPv6 route to be associated with a nexthop group that effectively contains only IPv4 members. A later IPv6 route lookup can then dereference a NULL nexthop pointer, causing a kernel panic and system crash.

Why it matters to the business

Successful exploitation can crash affected Linux systems, disrupting workloads, network routing functions, containers, virtualized hosts, appliances, or infrastructure services that depend on kernel network forwarding. The issue is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, and has a low EPSS score, so broad internet-scale exploitation is unlikely; however, systems where untrusted or semi-trusted users can modify routing state have higher operational risk.

How an attack unfolds

An attacker needs the ability to modify Linux routing and nexthop configuration, typically requiring root privileges or CAP_NET_ADMIN in the affected network namespace. The attacker first creates an IPv6 nexthop and places it into a nexthop group. They then replace that nexthop with an IPv4 nexthop in a way that leaves the group’s IPv4 tracking flag stale. Next, they add an IPv6 route that references the malformed nexthop group. When IPv6 traffic triggers a lookup for that route, the kernel follows the inconsistent nexthop state, receives a NULL nexthop for the IPv4 member, and panics due to a NULL pointer dereference. This is primarily a local or container/network-namespace-adjacent denial-of-service path rather than a remote code execution issue.

How to fix it

Upgrade to a Linux kernel version that contains the upstream fix for the nexthop family-change handling bug. The fix updates nexthop group IPv4 state whenever the nexthop address family changes, not only when changing from IPv4 to IPv6. If vendor-specific fixed package versions are not yet known, track the relevant Linux distribution kernel advisories and apply the first stable kernel update that references this CVE or the nexthop IPv6 route referencing IPv4 nexthop fix. As a mitigation, restrict the ability to create or replace nexthops and routes by limiting root access, removing CAP_NET_ADMIN from containers and services where it is not required, avoiding privileged containers, and monitoring or blocking untrusted use of `ip nexthop` and `ip -6 route` operations.

How to confirm the fix worked

Confirm the running kernel includes the vendor or upstream fix by checking the installed kernel package changelog, distribution advisory, or kernel commit history for the nexthop family-change update associated with this issue. Verify that systems have rebooted into the fixed kernel, because installing a kernel package alone does not protect a host still running an older kernel. Exposure can be assessed by identifying systems that allow local users, containers, or workloads to hold CAP_NET_ADMIN or otherwise modify nexthop and route configuration. In a controlled non-production test environment only, the published reproducer can be used to confirm whether an unfixed kernel panics; do not run the reproducer on production systems because it is designed to crash the host.

Typical attack path

1. Obtain sufficient privileges to change network routing state, such as root or CAP_NET_ADMIN in a Linux network namespace.
2. Create an IPv6 nexthop, for example an IPv6 blackhole nexthop.
3. Create a nexthop group that contains the IPv6 nexthop, causing the group to be marked as IPv6-only.
4. Replace the original nexthop with an IPv4 nexthop without correctly updating the group’s IPv4/IPv6 state on vulnerable kernels.
5. Add an IPv6 route that references the now-inconsistent nexthop group.
6. Trigger an IPv6 route lookup, such as by sending traffic to the affected IPv6 prefix.
7. Cause the kernel to dereference a NULL pointer and panic, resulting in a denial of service.

How to detect it

Look for evidence of both suspicious route manipulation and a subsequent kernel crash. Useful sources include auditd logs for command execution, shell history where available, sudo logs, systemd journal, kernel ring buffer logs, `/var/log/kern.log`, `/var/log/messages`, `/var/log/syslog`, crash dumps, and container runtime audit events showing workloads granted CAP_NET_ADMIN or privileged mode. Search for sequences involving `ip -6 nexthop add`, `ip nexthop add ... group`, `ip nexthop replace`, `ip -6 route add ... nhid`, followed by IPv6 traffic such as `ping -6` and then a kernel panic, oops, or NULL pointer dereference. Kernel crash artifacts may reference nexthop, IPv6 FIB, route lookup, or `nexthop_fib6_nh`. Since there are no known public exploitation campaigns or named threat actors for this issue, detection should focus on local abuse patterns and availability events rather than external network indicators.

• ip -6 nexthop add id 1 blackhole
• ip nexthop add id 100 group 1
• ip nexthop replace id 1 blackhole
• ip -6 route add 2001:db8::/64 nhid 100
• ping -6 2001:db8::1
• ip nexthop replace
• ip nexthop add
• ip -6 route add
• nhid
• BUG: kernel NULL pointer dereference
• kernel NULL pointer dereference
• nexthop_fib6_nh
• fib6_check_nexthop
• nh_group_v4_update
• nexthop: fix IPv6 route referencing IPv4 nexthop

What your security team should do

• Prioritize patching Linux systems where untrusted users, containers, network functions, or automation can modify routes or nexthops.
• Ensure patched systems are rebooted into the fixed kernel and verify the active kernel version after reboot.
• Audit container and service permissions and remove CAP_NET_ADMIN unless explicitly required.
• Avoid privileged containers for workloads that do not need host-level network administration capabilities.
• Monitor for use of `ip nexthop add`, `ip nexthop replace`, and `ip -6 route add ... nhid` commands, especially by unexpected users or processes.
• Review recent kernel panic, oops, and crash logs for NULL pointer dereferences in the nexthop or IPv6 FIB lookup path.
• For routing appliances or Linux-based network infrastructure, schedule patching during maintenance windows to reduce the risk of unexpected routing-service outages.
• Because EPSS is low and there is no KEV listing, treat this as important hardening and availability risk rather than an emergency internet-exposed remote compromise issue unless local privilege boundaries are weak.