A critical vulnerability in the Linux kernel’s IPv6 Segment Routing (SRv6) implementation allows remote, unauthenticated attackers to trigger a kernel panic by sending specially crafted packets. Tracked as CVE-2026-23442 with a CVSS v3.1 score of 8.2, the bug affects kernel versions 5.15 through 6.8 and has prompted emergency patch releases from every major distribution.

What Happened

The flaw lives in how the kernel handles SRv6 packets when the receiving network device lacks a valid IPv6 configuration. Two functions—seg6_hmac_validate_skb() and ipv6_srh_rcv()—call __in6_dev_get() to retrieve the in-device (idev) structure but never check for a NULL return. When the device has no IPv6 config (for example, when the interface MTU is below IPV6_MIN_MTU or during a NETDEV_UNREGISTER transition), the kernel dereferences a NULL pointer and panics.

This isn’t a theoretical risk. Unlike most kernel bugs that require local access or a compromised process, CVE-2026-23442 is remotely triggerable. An attacker can send malformed SRv6 packets with crafted routing headers to a vulnerable host and crash it outright. No authentication. No user interaction. Just a packet.

Technical Details

The root cause is a missing NULL guard in two code paths within the kernel’s Segment Routing subsystem:

  1. seg6_hmac_validate_skb() — Called during HMAC validation of SRv6 packets. If the incoming device has no IPv6 configuration, __in6_dev_get() returns NULL, and the subsequent dereference triggers a kernel oops.

  2. ipv6_srh_rcv() — The main receive handler for Segment Routing headers. Same pattern: it assumes __in6_dev_get() will always return a valid pointer.

The upstream fix (commit a25853c9feea) adds explicit NULL checks for idev in both functions. It’s a straightforward defensive fix—the kind of check that should have been there from the start.

Affected versions: Linux kernel 5.15 through 6.8. This spans RHEL 8/9, Ubuntu 22.04 LTS and later, Debian 11/12, and virtually every production Linux distribution currently in support.

Attack vector: Network-adjacent or remote. Any system with a publicly routable IPv6 address and SRv6-capable kernel modules loaded is a potential target. Data center hosts running SRv6 for traffic engineering are particularly exposed.

Who’s Affected

If you run Linux with IPv6 enabled—and in 2026, that’s most production infrastructure—you should pay attention. The blast radius is wide:

  • Cloud VMs and bare-metal hosts with public IPv6 addresses
  • Kubernetes nodes in dual-stack or IPv6-only clusters
  • Network appliances running Linux-based routing stacks with SRv6
  • Edge and CDN infrastructure processing untrusted IPv6 traffic
  • Containers don’t help here—this is a host kernel bug, and a crash takes down every container on the node

The CVSS score of 8.2 reflects the remote attack vector and high availability impact. There’s no confidentiality or integrity impact—this is a pure denial-of-service bug—but crashing production kernels is bad enough.

Mitigation

Patch immediately. All major distributions have released updates:

  • Red Hat: Kernel updates for RHEL 8 and 9 via standard security channels (RHSA-2026:2594)
  • Ubuntu: Patched kernels for 22.04 LTS and later
  • Debian: Security updates for Debian 11 (Bullseye) and 12 (Bookworm)

If you can’t patch immediately, consider these short-term mitigations:

  1. Disable SRv6 processing if you don’t need it:
    1

    sysctl -w net.ipv6.conf.all.seg6_enabled=0
  2. Filter SRv6 packets at the network edge. Drop IPv6 packets with Routing Header Type 4 (SRH) at your border if you don’t use Segment Routing.
  3. Restrict IPv6 exposure. If hosts don’t need public IPv6 addresses, don’t assign them.

The Bigger Picture

SRv6 adoption is growing fast in data center and service provider networks. It’s the backbone of modern IPv6 traffic engineering, enabling source-routed paths without MPLS overhead. But with adoption comes attack surface.

This is the second significant SRv6-related kernel vulnerability in the past year, following earlier issues in the seg6 netlink interface. The pattern suggests that the SRv6 code paths haven’t received the same level of security scrutiny as older, more established parts of the IPv6 stack.

If you’re running SRv6 in production, audit your exposure. If you’re not running SRv6 but have the modules loaded, disable them. And either way, patch your kernels.

References