CVE-2026-31685

What it actually does

This is an improper input validation flaw in the Linux kernel netfilter IPv6 EUI-64 match module. The vulnerable code path in ip6t_eui64 can access the packet Ethernet header via eth_hdr(skb) without first confirming that the socket buffer has a valid MAC header for all packet cases. A crafted IPv6 packet reaching a firewall rule that uses the eui64 match can therefore trigger invalid kernel memory access. Depending on kernel build, packet path, and memory layout, the result may include kernel crash, denial of service, or exposure/corruption of kernel memory. The issue is remotely reachable when affected systems process attacker-controlled IPv6 traffic through netfilter rules using the EUI-64 match.

Why it matters to the business

Systems that use affected Linux kernels and IPv6 firewall rules involving the EUI-64 match may be vulnerable to remote disruption. A successful attack could crash servers, firewalls, routers, appliances, container hosts, or network security gateways, causing service outages and operational instability. Although EPSS is currently low and no known exploited status is reported, the CVSS score is critical-level and the affected component is widely deployed through Linux distributions and downstream products, so exposure should be treated seriously where IPv6 filtering is enabled.

How an attack unfolds

An attacker first identifies a Linux-based target that accepts or forwards IPv6 traffic and has netfilter/ip6tables rules using the eui64 match. The attacker then sends specially crafted IPv6 packets that cause the netfilter eui64 matching function to evaluate a packet whose socket buffer does not contain a valid MAC header. In vulnerable kernels, the code may still call eth_hdr(skb) and derive an address from invalid header data instead of rejecting the packet. This can result in an invalid kernel memory access, causing a kernel oops, panic, service interruption, or potentially other memory-safety side effects depending on the environment. Exploitation does not require authentication or user interaction, but it does require that traffic reach the vulnerable netfilter rule path.

How to fix it

Upgrade to a Linux kernel version from the relevant distribution or vendor that includes the netfilter ip6t_eui64 fix rejecting invalid MAC headers before eth_hdr(skb) access. No exact fixed version was provided in the input, so use vendor advisories for the installed distribution, appliance, container host OS, hypervisor host, and embedded/network device firmware. As a mitigation until patching is complete, remove or disable ip6tables/ip66tables rules that use the eui64 match where feasible, restrict untrusted IPv6 traffic before it reaches affected hosts, disable IPv6 only where operationally acceptable, and avoid exposing affected systems directly to untrusted networks. Reboot into the patched kernel after installation; merely installing kernel packages is not sufficient if the running kernel remains vulnerable.

How to confirm the fix worked

Confirm the running kernel, not only the installed package, has been updated by checking uname -r and the distribution package changelog/advisory for the netfilter ip6t_eui64 fix. Review active IPv6 firewall rules for use of the EUI-64 match with commands such as ip6tables-save, nft list ruleset, and lsmod/modinfo for ip6t_eui64 or xt_eui64 depending on the platform. Validate that the vulnerable module is no longer present or that the running kernel includes the patch. Confirm systems have been rebooted into the fixed kernel. Where possible, perform controlled negative testing in a lab by sending malformed IPv6 traffic toward an eui64 rule and confirming the system rejects traffic without kernel warnings, oopses, panics, or packet-processing instability.

Typical attack path

1. Probe the target for reachable IPv6 services, routing, or firewall behavior.
2. Identify or infer that the target uses Linux netfilter/ip6tables with the IPv6 eui64 match enabled.
3. Send crafted IPv6 packets designed to traverse the vulnerable rule path with an invalid or absent MAC header context.
4. Trigger ip6t_eui64/eui64_mt6 processing before the kernel validates the MAC header.
5. Cause a kernel fault, crash, or unstable behavior, resulting in denial of service or possible kernel memory impact.

How to detect it

To determine whether exploitation may have occurred, review kernel logs, system journals, crash dumps, and network telemetry around any unexplained reboot, kernel panic, firewall failure, or IPv6 packet-processing anomaly. Relevant log sources include journald, /var/log/kern.log, /var/log/messages, dmesg output, kdump/vmcore data, appliance crash logs, hypervisor host logs, and SIEM-ingested syslog. Look for kernel oops or panic traces containing eui64_mt6, ip6t_eui64, eth_hdr, nf_hook_slow, ip6_tables, x_tables, or IPv6 forwarding/PREROUTING/INPUT paths. Correlate crash times with spikes in malformed IPv6 packets, unusual fragmented IPv6 traffic, tunnel/encapsulation traffic, or packets arriving on interfaces where no normal Ethernet MAC header should be expected. Also review firewall configuration history for active -m eui64 rules, because exploitation is only expected where the vulnerable match can be reached. There are no public threat actors, ransomware campaigns, or known exploited status associated with this CVE in the supplied data, so detection should focus on crash forensics and anomalous IPv6 traffic rather than actor-specific infrastructure.

• eui64_mt6
• ip6t_eui64
• xt_eui64
• eth_hdr
• BUG: kernel NULL pointer dereference
• general protection fault
• kernel panic
• Oops:
• RIP: eui64_mt6
• Call Trace: eui64_mt6
• Call Trace: ip6t_eui64
• nf_hook_slow
• ip6_tables
• x_tables
• ip6tables-save | grep eui64
• -m eui64
• /proc/net/ip6_tables_matches
• /lib/modules/*/kernel/net/ipv6/netfilter/ip6t_eui64.ko
• /var/log/kern.log
• /var/log/messages
• /var/crash/
• /proc/vmcore

What your security team should do

• Prioritize patching Linux systems that process untrusted IPv6 traffic and use ip6tables/netfilter EUI-64 matching, especially internet-facing servers, network appliances, routers, firewalls, Kubernetes/container hosts, and virtualization hosts.
• Inventory active IPv6 firewall rules and identify any use of -m eui64, ip6t_eui64, or equivalent netfilter matches.
• If immediate patching is not possible, remove EUI-64 match rules or place upstream filtering in front of affected systems to block untrusted IPv6 traffic from reaching the vulnerable path.
• Ensure kernel updates are followed by reboots or live-patching verification so that the fixed kernel is actually running.
• Monitor kernel logs for oops, panic, NULL pointer dereference, general protection fault, or page fault messages involving eui64_mt6, ip6t_eui64, eth_hdr, netfilter, ip6tables, or IPv6 packet processing.
• Treat unexplained reboots or crashes of IPv6-capable Linux network infrastructure as potentially suspicious until logs and packet telemetry are reviewed.
• Track vendor advisories for exact fixed package versions because the upstream fixed versions were not provided in the supplied data.