CVE-2026-53012: Linux Kernel Use-After-Free Vulnerability

CVE-2026-53012 Overview

CVE-2026-53012 is a Linux kernel vulnerability in the nexthop subsystem that allows a local attacker to trigger a NULL pointer dereference. The flaw resides in the IPv6 routing code path that interacts with replaced IPv4 nexthop entries. When an IPv6 nexthop is replaced with an IPv4 nexthop, the has_v4 flag on parent nexthop groups is not refreshed, allowing IPv6 routes to attach to groups containing only AF_INET members. A subsequent IPv6 route lookup calls nexthop_fib6_nh(), which returns NULL, producing a kernel panic. The issue was reported by syzbot and resolved upstream.

Critical Impact
A local user with CAP_NET_ADMIN can trigger a kernel NULL pointer dereference and denial of service through standard ip nexthop and ip -6 route commands.

Affected Products

Linux kernel versions containing the nexthop group has_v4 update logic prior to the upstream fix
Distributions shipping stable kernels referenced in the kernel.org commit set
Systems exposing the ip nexthop interface to privileged namespaces or containers

Discovery Timeline

2026-06-24 - CVE-2026-53012 published to NVD
2026-06-24 - Last updated in NVD database

Technical Details for CVE-2026-53012

Vulnerability Analysis

The vulnerability is a NULL pointer dereference [CWE-476] in the Linux kernel nexthop subsystem. Nexthop groups maintain a has_v4 flag indicating whether any member nexthop uses AF_INET. The kernel relies on this flag in fib6_check_nexthop to reject IPv6 routes that point to groups containing IPv4 members. The check exists because IPv6 forwarding paths cannot dereference IPv4-only nexthops at runtime.

The kernel only invoked nh_group_v4_update when replacing an AF_INET nexthop with AF_INET6. The reverse transition, AF_INET6 to AF_INET, did not refresh the flag. A group originally constructed with an IPv6 member retains has_v4=false even after its member is replaced by an IPv4 nexthop. This stale state defeats the fib6_check_nexthop guard.

Root Cause

The root cause is an incomplete state update in the nexthop replacement code path. The has_v4 flag was treated as a one-way transition rather than a value that must be recomputed on any family change. As a result, the invariant enforced by fib6_check_nexthop no longer held after a v6-to-v4 replacement.

Attack Vector

An attacker with privileges to configure nexthops reproduces the panic with a short sequence: create an IPv6 blackhole nexthop with ip -6 nexthop add id 1 blackhole, wrap it in a group with ip nexthop add id 100 group 1, then replace the member with an IPv4 nexthop using ip nexthop replace id 1 blackhole. The group's has_v4 flag remains false. The attacker then attaches an IPv6 route with ip -6 route add 2001:db8::/64 nhid 100 and sends IPv6 traffic. The lookup invokes nexthop_fib6_nh() on the IPv4 member, which returns NULL, and the subsequent dereference panics the kernel.

No verified exploit code is published. The reproducer is documented in the syzbot reports linked from the kernel commit set.

Detection Methods for CVE-2026-53012

Indicators of Compromise

Kernel oops or panic logs referencing nexthop_fib6_nh or fib6_check_nexthop in the call trace
Unexpected host or container reboots correlated with RTM_NEWNEXTHOP or RTM_NEWROUTE netlink events
Audit records showing ip nexthop replace operations from non-administrative workloads

Detection Strategies

Monitor /var/log/kern.log and dmesg for NULL pointer dereferences originating in net/ipv4/nexthop.c or net/ipv6/route.c
Inspect netlink audit trails for nexthop replacement sequences that change a member's address family
Correlate kernel crashes with preceding ip -6 route add ... nhid commands referencing recently modified nexthop groups

Monitoring Recommendations

Enable kdump to capture vmcores for any kernel panic in the routing subsystem
Track use of CAP_NET_ADMIN inside containers and unprivileged user namespaces
Alert on repeated nexthop family transitions on the same id within short time windows

How to Mitigate CVE-2026-53012

Immediate Actions Required

Apply the upstream stable kernel updates that call nh_group_v4_update on any family change, not only AF_INET to AF_INET6
Restrict CAP_NET_ADMIN in untrusted containers and user namespaces until kernels are patched
Audit running workloads for legitimate use of nexthop groups and replacement operations

Patch Information

The fix calls nh_group_v4_update whenever the replaced nexthop's family differs from the original, ensuring has_v4 is recomputed in both directions. Fix commits are available on kernel.org: 29c95185ba32, 613c8f4a5014, 6275796f22bb, 9c2d6770a5f4, aaac3bed0342, ad85961004fd, b3b7e850e154, and ceffe81a0be9.

Workarounds

Disable unprivileged user namespaces where CAP_NET_ADMIN could be acquired by untrusted code
Avoid configurations that mix AF_INET and AF_INET6 members within the same nexthop group
Remove or pin nexthop management tooling to administrative roles using SELinux or AppArmor policy

bash

# Restrict unprivileged user namespaces as a temporary mitigation
sysctl -w kernel.unprivileged_userns_clone=0

# Verify running kernel version against fixed stable releases
uname -r