CVE-2026-53214

What it actually does

This is a Linux kernel IPv6 networking flaw in cleanup_prefix_route() where addrconf_get_prefix_route() may return the fib6_null_entry sentinel route. That sentinel has a NULL fib6_table pointer, and the vulnerable code attempts to update route expiration state without first excluding the sentinel, causing a NULL pointer dereference/general protection fault in kernel context. The practical technical impact is a local denial of service: a crafted IPv6 address deletion or route-cleanup sequence through rtnetlink/netlink can trigger a kernel oops and may crash or destabilize the host, depending on kernel panic-on-oops settings and distribution hardening.

Why it matters to the business

Successful exploitation can interrupt Linux systems by crashing or destabilizing the kernel networking stack, causing service outages, workload disruption, node reboots, or loss of availability for applications hosted on affected systems. Risk is lower than remotely exploitable flaws because exploitation appears to require local ability to manipulate IPv6 network configuration, typically CAP_NET_ADMIN or equivalent privileges, but containerized or namespace-enabled environments may increase exposure if users or workloads can obtain network-administration capabilities. The vulnerability is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, has very low EPSS, and no public exploit maturity is reported, so remediation should be prioritized based on exposure of multi-tenant Linux hosts, container platforms, and systems where untrusted users can interact with network namespaces.

How an attack unfolds

An attacker first gains local code execution or access to a context capable of sending rtnetlink messages that alter IPv6 address configuration. They then craft or sequence IPv6 address deletion operations so that cleanup_prefix_route() looks up a prefix route and receives the fib6_null_entry sentinel instead of a normal route. In vulnerable kernels, the cleanup path does not check for this sentinel before accessing route table state. The kernel dereferences a NULL fib6_table pointer, producing a general protection fault or NULL pointer dereference in the IPv6 address-configuration path. If the system is configured to panic on oops, the host may reboot; otherwise, kernel networking or the calling process may become unstable and availability can still be affected.

How to fix it

Update to a Linux kernel build that includes the upstream fix for the IPv6 cleanup_prefix_route() NULL pointer dereference. Because no product-specific fixed versions were provided, use the latest security kernel from the operating-system vendor or distribution channel and confirm that the patch checking for fib6_null_entry before updating route expiration has been backported. Reboot into the patched kernel after installation. As interim mitigations, restrict CAP_NET_ADMIN and network-namespace creation to trusted users/workloads, avoid granting containers elevated network administration capabilities, disable unprivileged user namespaces where operationally acceptable, and consider disabling IPv6 only where it is not required and where doing so is compatible with business operations.

How to confirm the fix worked

Confirm the running kernel has been updated, not just installed, by checking the active kernel version after reboot and comparing it with the vendor advisory or package changelog that includes the fix for cleanup_prefix_route() / fib6_null_entry. Review distribution kernel changelogs for references to the IPv6 NULL pointer dereference, cleanup_prefix_route(), addrconf_get_prefix_route(), or fib6_null_entry. Validate exposure controls by confirming untrusted users and containers do not have CAP_NET_ADMIN and cannot create privileged network namespaces unless required. For high-assurance validation in a test environment only, exercise IPv6 address add/delete operations through rtnetlink on the patched kernel and verify no kernel oops or crash occurs.

Typical attack path

1. Obtain local execution on an affected Linux system or in a container/network namespace with sufficient network administration capability.
2. Use netlink/rtnetlink, directly or via tools such as iproute2, to manipulate IPv6 address configuration.
3. Trigger an IPv6 address deletion path that invokes ipv6_del_addr(), inet6_addr_del(), inet6_rtm_deladdr(), and cleanup_prefix_route().
4. Cause addrconf_get_prefix_route() to return the fib6_null_entry sentinel route.
5. Trigger the vulnerable NULL pointer dereference when cleanup_prefix_route() accesses route table state.
6. Cause a kernel oops, service disruption, or full system crash/reboot depending on kernel configuration.

How to detect it

Look for evidence of attempted or successful triggering in kernel and system logs rather than network perimeter logs, because exploitation is local through rtnetlink. Relevant sources include dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, system crash dumps, kdump/vmcore records, auditd logs for network configuration changes, sudo logs, shell history where available, and container runtime/Kubernetes audit logs showing privileged containers or CAP_NET_ADMIN use. Search for kernel oops, general protection fault, KASAN NULL pointer dereference, and call traces containing cleanup_prefix_route(), ipv6_del_addr(), inet6_rtm_deladdr(), addrconf_get_prefix_route(), or fib6_null_entry. Correlate crash times with commands or API calls that delete IPv6 addresses, such as ip -6 addr del, ip addr del, netlink-based network managers, container lifecycle events, or suspicious processes invoking network reconfiguration. A successful exploit may leave only a kernel crash/oops and reboot record; absence of a user-space payload does not rule out denial-of-service exploitation.

• cleanup_prefix_route
• addrconf_get_prefix_route
• fib6_null_entry
• ipv6_del_addr
• inet6_addr_del
• inet6_rtm_deladdr
• rtnetlink_rcv_msg
• KASAN: null-ptr-deref
• Oops: general protection fault
• NULL pointer dereference
• general protection fault, probably for non-canonical address
• net/ipv6/addrconf.c
• ip -6 addr del
• ip addr del
• CAP_NET_ADMIN

What your security team should do

• Inventory Linux systems running IPv6-enabled kernels, especially container hosts, Kubernetes nodes, CI runners, multi-user systems, and systems that allow network namespaces.
• Prioritize patching systems where untrusted users or workloads may have CAP_NET_ADMIN, privileged containers, host networking, or the ability to create network namespaces.
• Apply vendor-provided kernel security updates and reboot into the fixed kernel; verify the active running kernel is patched.
• Restrict CAP_NET_ADMIN, privileged containers, and unprivileged user namespaces where they are not required.
• Monitor kernel logs for IPv6 addrconf crashes, NULL pointer dereferences, general protection faults, or call traces involving cleanup_prefix_route().
• Treat unexpected kernel oops or reboot events on affected systems as potential exploitation or reliability incidents and preserve logs before rotation.
• Because EPSS is very low, no KEV listing exists, and no exploit maturity is reported, balance urgency against local exposure and privilege boundaries rather than treating this as a broadly internet-exploitable issue.