CVE-2026-31668

What it actually does

The flaw is in the Linux kernel Segment Routing over IPv6 (SRv6/seg6) lightweight tunnel implementation. A single destination route cache is shared between packet input and output processing paths even though those paths may require different routing-table lookups, policy-routing rules, ingress-interface handling, or VRF separation. If one path populates the cache first, the other path can incorrectly reuse that cached route and bypass its own routing decision. The practical technical impact is incorrect forwarding, routing-policy bypass, VRF or interface isolation bypass, traffic redirection, unintended packet delivery, and potential denial of service or exposure of traffic to paths that should not receive it. This is not described as memory corruption or arbitrary code execution; the risk is primarily network-policy and routing-boundary compromise in systems using SRv6/seg6 lwtunnel routes.

Why it matters to the business

Organizations using Linux systems as routers, gateways, service-provider edge devices, cloud networking nodes, Kubernetes/CNI dataplanes, or network appliances with SRv6 enabled could have traffic forwarded through unintended paths or across boundaries that are meant to be isolated. This can undermine segmentation, tenant or VRF separation, compliance controls, and availability of routed services. Although EPSS is currently low and there is no known KEV listing or public exploit maturity reported, the high CVSS score reflects that exploitation can be remote, unauthenticated, and impactful where vulnerable SRv6 configurations are exposed.

How an attack unfolds

An attacker must be able to send or influence IPv6/SRv6 traffic that is processed by a vulnerable Linux kernel using seg6 lightweight tunnel routes. The attacker targets a host or router where input and output SRv6 paths can resolve the post-encapsulation Segment Identifier through different routing contexts, such as policy routing rules tied to ingress interface or VRF-separated routing tables. By causing one processing path to populate the shared destination cache, the attacker can then send traffic that is handled by the other path and cause it to reuse the stale or context-inappropriate cached route. This can bypass the intended route lookup and send traffic along a path that should have been disallowed, isolated, or differently routed. Successful exploitation depends heavily on network role and configuration: systems not using SRv6/seg6 lwtunnel routes are unlikely to be exposed.

How to fix it

Apply a Linux kernel update from the operating-system or appliance vendor that includes the fix separating the seg6 lwtunnel destination cache into independent input and output caches. Because no exact fixed package versions were provided, use vendor advisories for the deployed distribution, kernel stream, appliance firmware, or cloud image to identify the corrected version. Where immediate patching is not possible, reduce exposure by disabling unused SRv6/seg6 functionality, removing unnecessary seg6 lwtunnel routes, limiting who can send IPv6/SRv6 traffic to affected routers, enforcing strict ingress filtering, and reviewing VRF/policy-routing configurations that rely on interface or table separation. Mitigations should be treated as temporary because the safest fix is a kernel containing the cache separation patch.

How to confirm the fix worked

Confirm remediation by verifying the running kernel, not only the installed package, has been updated to a vendor build containing the seg6 lwtunnel cache split fix. Reboot or live-patch as required by the vendor so the corrected kernel is active. Review SRv6 exposure with commands such as `ip -6 route show`, `ip -6 route show table all`, `ip -6 rule show`, `ip -d -6 route show`, and VRF configuration checks to determine whether seg6 lwtunnel routes are present. Validate routing behavior with controlled test traffic across both SRv6 input and output paths, especially where ingress-interface policy rules or VRF separation are expected to produce different route lookups. Confirm that traffic follows the intended routing table and does not cross policy or VRF boundaries after the fix.

Typical attack path

1. Identify or reach a Linux-based router, gateway, or network node that processes IPv6 SRv6/seg6 lightweight tunnel traffic.
2. Determine or infer that the target uses policy routing, ingress-interface-based rules, or VRF/table separation where SRv6 input and output paths should resolve routes differently.
3. Send crafted or sequenced SRv6 traffic that causes either the input or output processing path to populate the shared destination route cache.
4. Send additional traffic that is processed by the opposite path and incorrectly reuses the cached destination from the first path.
5. Leverage the incorrect cached route to bypass routing policy, cross an isolation boundary, redirect traffic, expose traffic to an unintended network path, or disrupt forwarding behavior.

How to detect it

This issue is difficult to detect after the fact because exploitation may look like valid IPv6/SRv6 forwarding rather than a crash, login, file write, or command execution event. Focus on network telemetry and routing evidence from systems that use SRv6/seg6 lwtunnel routes. Review router, firewall, NetFlow/IPFIX, packet-capture, and kernel/network logs for IPv6 Segment Routing traffic crossing interfaces, VRFs, tenants, or routing tables that should be isolated. Compare observed traffic paths with expected `ip -6 rule`, VRF, and route-table behavior. Look for asymmetric or unexpected forwarding decisions occurring after SRv6 traffic on either input or output paths. If available, inspect historical configuration-management data for seg6 lwtunnel routes and correlate with unexplained segmentation bypasses, traffic leakage, or service disruption. There are no reliable public, payload-specific indicators from the provided data; detection should therefore be behavior- and configuration-driven.

What your security team should do

• Prioritize patching Linux routers, gateways, network appliances, hypervisors, cloud networking nodes, and container networking hosts that use IPv6 SRv6/seg6 features.
• Inventory systems with seg6 lwtunnel routes and VRF or policy-routing configurations; systems without SRv6/seg6 use are lower priority.
• Use vendor kernel advisories to identify the corrected kernel version because fixed versions were not supplied in the input data.
• If patching is delayed, disable unused SRv6/seg6 functionality and restrict IPv6/SRv6 traffic to trusted peers and expected interfaces.
• Review segmentation assumptions for VRF, tenant, service-chain, or routing-policy boundaries that depend on Linux SRv6 forwarding behavior.
• Increase monitoring for unexpected IPv6 routing decisions, SRv6 packet flows, route-cache-related anomalies, and traffic crossing normally isolated routing domains.
• Because the vulnerability is not currently listed in KEV and EPSS is low, treat it as high impact but configuration-dependent rather than broadly internet-exploited at this time.