CVE-2026-63969

What it actually does

This is a Linux kernel IPv6 routing bug that can cause an infinite loop in rt6_fill_node() while walking IPv6 FIB route sibling lists. A route entry can be removed with list_del_rcu() while softirq-side or netlink dump readers are still traversing the old list. Because the removed entry’s fib6_siblings pointer may still reference the prior ring, the walker may never reach the expected list head and can spin indefinitely. The practical technical result is CPU stall or soft lockup in kernel context, potentially degrading or denying service on systems using IPv6 routing functionality.

Why it matters to the business

Successful exploitation or accidental triggering can cause affected Linux systems to consume CPU, become sluggish, stop responding to network operations, or require reboot/recovery. This is most concerning for routers, firewalls, load balancers, Kubernetes nodes, VPN gateways, and servers that use IPv6 or expose routing/netlink functionality. Current public exploit maturity is listed as none, EPSS is low, and it is not in the CISA KEV catalog, so urgency is lower than actively exploited kernel bugs; however, internet-facing or high-availability Linux infrastructure should still prioritize kernel updates because denial-of-service conditions can have direct outage impact.

How an attack unfolds

An attacker would need to cause or influence IPv6 routing table activity that exercises the vulnerable rt6_fill_node() traversal path while routes are concurrently being deleted or modified. In a realistic scenario, this could involve generating IPv6 routing churn, triggering route dumps through netlink-capable local activity, or abusing a service or configuration that causes frequent IPv6 route updates. If the race condition is hit, the kernel route-list walker can loop forever on a stale sibling list pointer, causing a CPU stall or soft lockup. The attack outcome is denial of service rather than code execution or data theft. Because this is a kernel concurrency flaw, exploitation reliability may depend heavily on timing, routing configuration, kernel version, CPU load, and whether IPv6 routing paths are actively used.

How to fix it

Upgrade to a Linux kernel version that includes the upstream fix for the IPv6 rt6_fill_node() infinite-loop condition. If using a distribution kernel, apply the vendor security update rather than relying only on upstream version numbers, because fixes are often backported. No exact affected product list or fixed package versions were provided, so administrators should check their Linux distribution advisories for CVE-2026-63969 or for the patch referencing the IPv6 rt6_fill_node() sibling-list detach fix. Where immediate patching is not possible, reduce exposure by disabling IPv6 only where operationally safe, limiting local access to netlink/routing capabilities, restricting untrusted containers from NET_ADMIN or host networking privileges, reducing unnecessary dynamic IPv6 route churn, and ensuring watchdog/reboot automation exists for critical systems that may hard-lock or soft-lock.

How to confirm the fix worked

Confirm the running kernel includes the vendor fix by checking the installed package changelog, distribution advisory, or kernel source/patch history for the rt6_fill_node() fix that checks fib6_nsiblings as a detach signal during sibling traversal. Validate the running kernel version after reboot with uname -a and package manager queries, ensuring the patched kernel is actually booted. On source-built kernels, verify the IPv6 route dump code contains the corrected inside-loop check for detached sibling entries. Exposure can be assessed by confirming whether IPv6 is enabled, whether the host performs IPv6 routing, and whether untrusted users, containers, or services can trigger route changes or rtnetlink dumps. Functional validation should include normal IPv6 route add/delete and route dump operations while monitoring dmesg/journal logs for soft lockups, RCU stalls, or stack traces involving rt6_fill_node().

Typical attack path

1. Identify a Linux system running an affected kernel with IPv6 enabled and routing-table activity exposed or inducible.
2. Create or influence IPv6 route churn, such as frequent route additions, deletions, neighbor/routing changes, or traffic patterns that cause route updates.
3. Trigger code paths that dump or traverse IPv6 route entries, including rtnetlink/IPv6 FIB dump behavior where applicable.
4. Race route deletion against route traversal so an RCU reader observes a detached fib6_siblings list entry.
5. Cause rt6_fill_node() to loop indefinitely, leading to kernel CPU stall, soft lockup, degraded networking, or system unresponsiveness.

How to detect it

To determine whether this issue may already have been triggered, review kernel logs and system journals for CPU stall, RCU stall, soft lockup, or watchdog messages around periods of IPv6 routing churn or network instability. Useful log sources include dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, /var/log/syslog, crash dumps, kdump/vmcore analysis, hypervisor console logs, and network monitoring showing sudden loss of responsiveness. Look for stack traces containing rt6_fill_node(), IPv6 route dump functions, fib6 route functions, rtnetlink handlers, or repeated CPU stall messages without an obvious hardware cause. Correlate events with route changes, netlink route dumps, container/network orchestration activity, routing daemon restarts, IPv6 neighbor/routing updates, or spikes in IPv6 control-plane traffic. Because this vulnerability causes denial of service rather than leaving a stable file or process artifact, detection is primarily based on kernel telemetry, crash artifacts, and timing correlation rather than durable host IOCs.

• rt6_fill_node
• fib6_info_uses_dev
• fib6_del_route
• fib6_siblings
• fib6_nsiblings
• inet6_dump_fib
• fib6_dump_table
• rtnetlink_rcv_msg
• BUG: soft lockup - CPU#
• NMI watchdog: BUG: soft lockup
• watchdog: BUG: soft lockup
• rcu: INFO: rcu_sched detected stalls
• rcu: INFO: rcu_preempt detected stalls
• INFO: task hung in
• CPU stuck
• kernel: watchdog: Watchdog detected hard LOCKUP
• IPv6: RTM_GETROUTE
• RTM_GETROUTE

What your security team should do

• Inventory Linux systems with IPv6 enabled, especially routers, firewalls, load balancers, hypervisors, Kubernetes nodes, VPN gateways, and hosts granting NET_ADMIN to containers or services.
• Track vendor advisories and apply the patched Linux kernel when available; prioritize high-availability and network-edge systems first.
• After patching, reboot into the fixed kernel and verify the active runtime kernel, not just the installed package version.
• Temporarily restrict untrusted local users, containers, and workloads from network administration capabilities such as CAP_NET_ADMIN where feasible.
• Disable IPv6 only if it is not required and the change has been operationally tested.
• Monitor kernel logs for CPU stalls, RCU stalls, soft lockups, and stack traces containing rt6_fill_node or IPv6 FIB dump functions.
• Prepare operational recovery procedures for affected high-availability systems, including watchdog configuration and safe failover, because the primary impact is denial of service.
• Treat the current risk as moderate: EPSS is low, there is no KEV listing, and no public exploit maturity is reported, but kernel DoS bugs can still cause severe outages in routing-heavy environments.