CVE-2026-46260

What it actually does

This is a Linux kernel memory-corruption vulnerability in the IPv6 routing code. When an IPv6 route is added through rtnetlink using an RTA_NH_ID next-hop identifier, the kernel may create a fib6_info object without an embedded trailing fib6_nh structure. The vulnerable path in fib6_add_rt2node() can then read from fib6_nh before confirming that the route uses a separate nexthop object, causing an out-of-bounds slab read. In practical terms, a local user able to issue relevant network-route netlink operations may be able to crash the kernel, disclose adjacent kernel memory, or potentially use the memory-safety condition as part of a local privilege-escalation chain depending on kernel configuration, hardening, and exploit development.

Why it matters to the business

Successful exploitation can affect host stability and confidentiality by causing kernel crashes, service outages, or possible exposure of sensitive kernel memory. Because the vulnerable component is in the Linux kernel, affected systems may include servers, containers hosts, appliances, network infrastructure, and embedded Linux platforms that run vulnerable kernel versions with IPv6 routing enabled. The issue is not currently listed in CISA KEV, is not reported as ransomware-used, has very low EPSS, and has no known public exploit maturity in the provided data, so broad internet-scale exploitation is unlikely; however, local attackers or compromised workloads can still use kernel vulnerabilities to increase impact after initial access.

How an attack unfolds

An attacker first needs local code execution or access to a context that can send route-management messages to the kernel, typically requiring CAP_NET_ADMIN or an environment where that capability can be obtained, such as a permissive container or user/network namespace configuration. The attacker crafts an RTM_NEWROUTE rtnetlink message for IPv6 that uses RTA_NH_ID, causing the kernel to allocate a fib6_info structure without the embedded fib6_nh layout expected by part of the route insertion logic. During route insertion, fib6_add_rt2node() evaluates existing route entries and incorrectly reads iter->fib6_nh before checking whether the route instead references a separate nexthop object. That read crosses the bounds of the allocated object. A simple exploit may trigger a kernel warning or panic, resulting in denial of service. More advanced exploitation would attempt to shape nearby slab allocations to convert the out-of-bounds read into kernel information disclosure or a building block for bypassing kernel memory protections, but no public exploit maturity is indicated in the provided data.

How to fix it

Upgrade affected Linux kernels to a vendor release that includes the upstream fix for the IPv6 fib6_add_rt2node() bounds-checking issue. Because no exact fixed package versions were provided, use the kernel advisory from the operating-system or appliance vendor and install the first kernel version that contains the patch changing the logic to check the nexthop pointer before accessing fib6_nh. Reboot into the patched kernel after installation; merely installing the package is not sufficient if the old kernel remains running. As interim mitigation, reduce exposure by restricting CAP_NET_ADMIN, disabling unprivileged user namespaces where operationally feasible, limiting container privileges, avoiding host-network or privileged containers unless required, and enforcing seccomp/AppArmor/SELinux profiles that prevent untrusted workloads from issuing network-administration operations. If IPv6 is not used, disabling IPv6 may reduce the reachable attack surface, but it should not be treated as a complete substitute for patching.

How to confirm the fix worked

Confirm the currently running kernel version, not just the installed package version, using commands such as uname -r and the distribution package manager. Verify that the installed vendor kernel changelog or security advisory includes the fix for the IPv6 fib6_add_rt2node() out-of-bounds access involving RTA_NH_ID. After reboot, ensure the patched kernel is active and older vulnerable kernels are not selected by default in the bootloader. Validate exposure by reviewing whether untrusted users, containers, or services have CAP_NET_ADMIN or can create user/network namespaces. Where safe in a non-production test environment, exercise IPv6 route addition with nexthop IDs and verify the system does not emit kernel KASAN, BUG, general protection fault, or panic messages referencing fib6_add_rt2node().

Typical attack path

1. Gain local execution on a Linux system running a vulnerable kernel.
2. Obtain or abuse permission to manage network routes, commonly CAP_NET_ADMIN or equivalent capability inside a network namespace.
3. Create or identify IPv6 routing state involving nexthop objects.
4. Send a crafted rtnetlink RTM_NEWROUTE message that adds an IPv6 route using RTA_NH_ID.
5. Trigger fib6_add_rt2node() while it processes route insertion and evaluates existing route entries.
6. Cause an out-of-bounds slab read in kernel memory.
7. Use the condition to crash the kernel or, with additional exploit work, attempt information disclosure or privilege escalation.

How to detect it

Look for evidence of prior exploitation in kernel logs, system journals, crash dumps, audit logs, and container runtime telemetry. Primary artifacts are kernel crash reports, KASAN reports, slab out-of-bounds messages, oops/panic events, or call traces containing fib6_add_rt2node(), fib6_add(), ip6_route_add(), inet6_rtm_newroute(), rtnetlink_rcv_msg(), or netlink_sendmsg(). On systems with auditd or eBPF telemetry, review route-management activity involving NETLINK_ROUTE, RTM_NEWROUTE, IPv6 route additions, and RTA_NH_ID-like nexthop usage, especially when initiated by unexpected users, containers, or service accounts. Also inspect recent privilege changes or container configurations granting CAP_NET_ADMIN. Kernel memory-corruption exploitation may leave no durable file-based artifact, so absence of IOCs does not prove absence of exploitation; prioritize correlation between anomalous route changes, local user activity, container privilege misuse, and kernel fault timestamps.

• BUG: KASAN: slab-out-of-bounds in fib6_add_rt2node
• slab-out-of-bounds in fib6_add_rt2node
• fib6_add_rt2node+
• net/ipv6/ip6_fib.c:1142
• fib6_add_rt2node_nh
• fib6_add+
• ip6_route_add+
• inet6_rtm_newroute+
• rtnetlink_rcv_msg+
• netlink_sendmsg+
• __x64_sys_sendmsg+
• RTM_NEWROUTE
• RTA_NH_ID
• NETLINK_ROUTE
• CAP_NET_ADMIN

What your security team should do

• Patch Linux kernels through the appropriate vendor channel and reboot into the fixed kernel, prioritizing multi-user systems, container hosts, CI runners, bastion systems, and shared compute platforms.
• Inventory workloads and hosts where untrusted users or containers have CAP_NET_ADMIN, privileged-container access, host networking, or permission to create network namespaces.
• Temporarily remove CAP_NET_ADMIN from containers and services that do not strictly require it.
• Disable or restrict unprivileged user namespaces where this is compatible with business requirements.
• Monitor kernel logs for crashes or sanitizer reports referencing fib6_add_rt2node, ip6_fib.c, inet6_rtm_newroute, or IPv6 route creation through rtnetlink.
• Review audit logs for unusual route-management activity by non-administrative users or application service accounts.
• Because this is not KEV-listed, not ransomware-associated in the provided data, and has low EPSS, handle as a high-impact local kernel hardening and patching priority rather than an emergency internet-exposed remote exploitation event.