CVE-2026-63968

What it actually does

This is a Linux kernel IPv6 networking denial-of-service flaw in the fib6_select_path() route-selection path. A race between IPv6 route-table writers deleting sibling route entries and RCU readers walking the sibling list can leave the reader traversing an old list ring without reaching its expected terminator. When this happens on the softirq networking path, the CPU can spin indefinitely or for an extended period, causing soft lockups, RCU stalls, packet-processing disruption, and potentially system-wide availability loss. The impact is availability-only; it does not provide direct confidentiality or integrity compromise.

Why it matters to the business

Affected Linux systems that process IPv6 traffic may become unstable or unavailable, disrupting applications, network services, containers, routing functions, or infrastructure workloads hosted on those systems. Because the flaw is remotely reachable according to the CVSS vector and requires no authentication or user interaction, externally exposed IPv6-capable servers, routers, load balancers, VPN gateways, Kubernetes nodes, and network appliances using affected kernels should be prioritized even though the current EPSS score is low and there is no known CISA KEV listing or public exploit maturity at this time.

How an attack unfolds

An attacker targets a Linux system that has IPv6 enabled and is running an affected kernel. The attacker sends IPv6 traffic that causes the kernel to perform IPv6 FIB route selection while route entries or route siblings are being updated, removed, or purged. If the race is hit, fib6_select_path() may continue walking a stale sibling list and fail to terminate as expected. Because this occurs in kernel networking context, the affected CPU can enter a softirq-side infinite loop, leading to soft lockup warnings, RCU stall messages, degraded packet forwarding, service timeouts, and in severe cases a host or appliance that requires reboot or failover recovery. No evidence is provided that this vulnerability is currently used by named threat actors or ransomware campaigns.

How to fix it

Upgrade to a Linux kernel build that includes the upstream fix for the IPv6 fib6_select_path() infinite-loop condition. Because no product-specific affected or fixed versions were provided, use the fixed kernel packages from the relevant Linux distribution, appliance vendor, cloud image provider, or embedded platform vendor rather than relying only on upstream version numbers. Prioritize internet-facing and IPv6-enabled systems. If immediate patching is not possible, reduce exposure by disabling IPv6 where it is not required, filtering untrusted IPv6 traffic at network boundaries, limiting access to IPv6 services, reducing unnecessary IPv6 multipath or route churn, and ensuring high-availability failover is available for critical network-facing systems. Mitigations should be treated as temporary because the underlying flaw is in kernel route-selection logic.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel package or appliance firmware includes the vendor fix for CVE-2026-63968, not merely that an updated package is installed but pending reboot. Validate with uname -a, package-manager query output, vendor advisory mapping, and reboot status checks. Confirm IPv6 exposure by checking whether IPv6 is enabled, whether IPv6 addresses are assigned, and whether services listen on IPv6 sockets. Review routing configuration for IPv6 multipath routes, dynamic routing daemons, containers, or network namespaces that may increase route churn. After patching, monitor kernel logs under representative IPv6 traffic for absence of soft lockups, RCU stalls, and call traces involving fib6_select_path().

Typical attack path

1. Identify a reachable Linux system or appliance with IPv6 enabled and an affected kernel.
2. Generate IPv6 traffic that repeatedly exercises IPv6 route lookup and path selection.
3. Increase the chance of hitting the race by targeting systems with dynamic IPv6 routes, multipath routes, route churn, namespace/container networking changes, or routing daemon activity.
4. Trigger the stale sibling-list traversal condition in fib6_select_path().
5. Cause kernel softirq CPU consumption, soft lockups, RCU stalls, packet-processing failure, or service unavailability.
6. Sustain traffic or repeat attempts to prolong denial of service until the system is patched, rebooted, isolated, or failed over.

How to detect it

Look for evidence of availability impact rather than traditional intrusion artifacts, because this flaw causes kernel-level denial of service and does not inherently create files, accounts, persistence, or command execution. Primary log sources are kernel ring buffer logs, system journal, syslog, crash dumps, hypervisor reset records, network device telemetry, routing daemon logs, and monitoring metrics. Search for soft lockup or RCU stall messages around periods of high IPv6 traffic, route changes, failovers, container/network namespace churn, or unexplained host unresponsiveness. In kernel logs and vmcores, prioritize call traces that include fib6_select_path(), IPv6 route lookup functions, ksoftirqd, NET_RX softirq activity, or high CPU consumption in networking interrupt context. Network telemetry may show spikes in IPv6 packets, repeated flows to IPv6-exposed services, or traffic preceding system lockups, but there may be no unique packet signature. If crash dumps are available, examine blocked CPUs and stack traces for looping in IPv6 fib6 sibling traversal. Correlate symptoms with uptime resets, watchdog events, HA failovers, and service availability alarms.

• fib6_select_path
• watchdog: BUG: soft lockup
• NMI watchdog: BUG: soft lockup
• rcu: INFO: rcu_sched self-detected stall
• rcu: INFO: rcu_preempt self-detected stall
• rcu: INFO: rcu_sched detected stalls on CPUs/tasks
• rcu: INFO: rcu_preempt detected stalls on CPUs/tasks
• Call Trace:
• ksoftirqd
• NET_RX
• IPv6:
• fib6
• ip6_pol_route
• ip6_route_input
• ip6_route_output
• rt6_select
• kernel: watchdog: BUG: soft lockup
• kernel: rcu: INFO:
• /var/log/kern.log
• /var/log/messages
• /var/log/syslog

What your security team should do

• Inventory Linux servers, appliances, container hosts, Kubernetes nodes, and network devices with IPv6 enabled and determine whether their running kernels include the vendor fix.
• Prioritize patching internet-facing, routing, load-balancing, VPN, firewall, DNS, mail, web, and container infrastructure that processes IPv6 traffic.
• Apply vendor kernel or firmware updates and reboot systems where required so the fixed kernel is actually running.
• Temporarily restrict or disable unnecessary IPv6 exposure until affected systems are patched.
• Search kernel logs for soft lockups, RCU stalls, and call traces referencing IPv6 FIB route selection or fib6_select_path().
• Review monitoring for unexplained CPU saturation in softirq/ksoftirqd, IPv6 packet loss, node unresponsiveness, failovers, or reboots since publication.
• Ensure critical IPv6-facing services have redundancy and operational runbooks for rapid failover or isolation if denial-of-service symptoms recur.
• Track distribution and appliance vendor advisories because fixed versions may differ across downstream kernel branches.