CVE-2026-64116

What it actually does

This Linux kernel flaw is a race-condition-triggered NULL pointer dereference in IPv6 IOAM Hop-by-Hop option handling. While processing an IPv6 packet containing an IOAM Hop-by-Hop option, ipv6_hop_ioam() dereferences the IPv6 per-interface structure returned by __in6_dev_get(skb->dev) without first confirming it is non-NULL. During concurrent network interface teardown, addrconf_ifdown() can clear dev->ip6_ptr under RCU, causing __in6_dev_get() to return NULL. If the vulnerable path is hit, the kernel can fault and crash, resulting in denial of service. The issue does not provide confidentiality or integrity impact by itself, but it can cause high availability impact on affected Linux systems that process IPv6 IOAM traffic.

Why it matters to the business

An unauthenticated network-based attacker may be able to crash affected Linux systems by sending crafted IPv6 traffic at the right time, potentially interrupting servers, network appliances, containers, routers, or hosts that rely on IPv6. The operational risk is highest for internet- or untrusted-network-facing systems, systems using IPv6 Hop-by-Hop option processing, and infrastructure where network interfaces are frequently created, removed, restarted, or reconfigured, such as virtualized, containerized, SDN, or cloud environments. The vulnerability is not currently listed in CISA KEV, has no known ransomware association, and has a low EPSS score, so broad exploitation is not indicated, but the CVSS availability impact is high and patching should be prioritized for exposed or availability-critical Linux systems.

How an attack unfolds

An attacker sends IPv6 packets containing Hop-by-Hop options that reach the IOAM processing path on a vulnerable Linux kernel. To trigger the crash, the packet processing must coincide with interface teardown or IPv6 device state changes where the kernel clears the interface IPv6 pointer. In that race window, ipv6_hop_ioam() calls __in6_dev_get() and receives NULL, then dereferences the missing structure while checking IOAM configuration. This causes a kernel NULL pointer dereference, which can lead to an oops or system panic depending on kernel configuration and panic-on-oops behavior. Successful exploitation is a denial-of-service event rather than code execution. No public exploit maturity or known threat actor exploitation is currently indicated from the provided data.

How to fix it

Apply the Linux kernel update that includes the fix adding a NULL check for the IPv6 interface device pointer in ipv6_hop_ioam() and dropping the packet with the appropriate IPv6-disabled reason when the pointer is absent. Because no exact affected or fixed package versions were provided, use the fixed kernel versions published by the relevant Linux distribution, appliance vendor, cloud image provider, or kernel source branch. Prioritize updates on IPv6-enabled systems exposed to untrusted networks and systems where a crash would cause service disruption. If immediate patching is not possible, reduce exposure by filtering IPv6 Hop-by-Hop options from untrusted networks where operationally safe, disabling or limiting IPv6 IOAM functionality if not required, restricting IPv6 reachability to trusted peers, and avoiding unnecessary interface churn on vulnerable systems. Mitigations should be validated carefully because dropping all IPv6 extension headers or Hop-by-Hop options may affect legitimate network functions in some environments.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel version matches a vendor release containing the CVE fix, not merely that an updated package is installed but not booted. On source-based or custom kernels, confirm that ipv6_hop_ioam() checks the result of __in6_dev_get(skb->dev) before dereferencing the returned pointer. Validate runtime status with commands such as uname -r and distribution package tools, then reboot if required to load the fixed kernel. Review whether IPv6 is enabled and whether untrusted traffic can reach systems using IPv6 Hop-by-Hop processing. Where safe in a non-production test environment, validate that crafted IPv6 IOAM Hop-by-Hop packets during interface teardown no longer cause a kernel oops or panic. For mitigations, confirm that network controls actually block or drop IPv6 Hop-by-Hop/IOAM traffic before it reaches vulnerable hosts.

Typical attack path

1. Identify Linux systems reachable over IPv6, especially systems that may process IPv6 Hop-by-Hop options or act as IPv6 routers/forwarders.
2. Send crafted IPv6 packets containing IOAM Hop-by-Hop options toward the target.
3. Increase timing opportunities by sustaining packet delivery while network interfaces are being restarted, removed, reconfigured, or otherwise torn down.
4. Trigger the race where addrconf_ifdown() clears the IPv6 interface pointer while ipv6_hop_ioam() processes the packet.
5. Cause a kernel NULL pointer dereference and potential host crash, service outage, or reboot.

How to detect it

To determine whether this was already exploited, review kernel and system logs for crashes, oops events, or panics that reference IPv6 IOAM, Hop-by-Hop option handling, ipv6_hop_ioam(), or __in6_dev_get(). Relevant sources include dmesg output, systemd journal entries, /var/log/kern.log, /var/log/messages, /var/log/syslog, kdump/vmcore records, hypervisor console logs, appliance crash logs, and monitoring alerts for unexpected reboots. Correlate any crash timestamps with network interface teardown events such as link down/up, NetworkManager restarts, container or virtual interface deletion, routing daemon restarts, or administrative interface changes. If packet captures, IDS telemetry, firewall logs, or flow metadata are available, look for IPv6 packets using the Hop-by-Hop Options extension header, especially packets containing IOAM options, arriving shortly before the crash. Absence of these artifacts does not rule out exploitation because kernel crashes may truncate logs and many environments do not log IPv6 extension header details by default.

• ipv6_hop_ioam
• __in6_dev_get
• ioam6_enabled
• addrconf_ifdown
• SKB_DROP_REASON_IPV6DISABLED
• BUG: kernel NULL pointer dereference
• Unable to handle kernel NULL pointer dereference
• RIP: 0010:ipv6_hop_ioam
• Oops: 0000
• Kernel panic - not syncing
• IPv6 Hop-by-Hop Options
• Hop-by-Hop Options Header
• IOAM Hop-by-Hop
• IPV6-IOAM
• Next Header: Hop-by-Hop Option
• IPv6 extension header: Hop-by-Hop

What your security team should do

• Inventory IPv6-enabled Linux systems, prioritizing internet-facing, network-edge, routing, virtualization, container, and availability-critical hosts.
• Apply vendor kernel updates containing the fix and reboot systems into the fixed kernel.
• If patching is delayed, block or rate-limit IPv6 Hop-by-Hop options from untrusted networks where compatible with business requirements.
• Review kernel logs for prior NULL pointer dereferences involving ipv6_hop_ioam, __in6_dev_get, IOAM, or IPv6 Hop-by-Hop processing.
• Monitor for unusual volumes of IPv6 packets with Hop-by-Hop extension headers or IOAM options, especially near interface restart or link-state events.
• Ensure crash handling, watchdog, and high-availability failover behavior is appropriate for systems that could be affected by kernel panics.
• Track vendor advisories for exact fixed kernel/package versions because fixed_versions were not provided in the input.