CVE-2026-43037

What it actually does

This is a remotely reachable Linux kernel memory-corruption flaw in the IPv4-over-IPv6 tunnel error-handling path. When ip4ip6_err() processes certain IPv6 tunnel error traffic, it clones a socket buffer whose control buffer still contains IPv6 receive-path metadata. That same memory is later interpreted as IPv4 metadata by icmp_send() and __ip_options_echo(). Because the IPv6 and IPv4 control-buffer layouts differ, attacker-influenced packet data can cause __ip_options_echo() to copy an excessive length into a fixed 40-byte stack buffer used for IPv4 options. The result is a kernel stack buffer overflow that can plausibly lead to kernel crash, denial of service, information corruption, or, under favorable conditions, kernel-mode code execution. The fix clears skb->cb before reuse and adds minimal IPv4 header validation.

Why it matters to the business

Systems running vulnerable Linux kernels with IPv4-over-IPv6 tunneling functionality exposed may be remotely crashable and potentially fully compromisable without authentication or user interaction. A successful attack could interrupt network services, take down tunnel endpoints, or give an attacker kernel-level control of affected hosts. Although EPSS is currently low and there is no known KEV listing or public exploit maturity reported, the CVSS score is critical and the bug is in kernel networking code, so internet-facing tunnel infrastructure, routers, gateways, appliances, container hosts, and cloud images based on affected kernels should be prioritized.

How an attack unfolds

An attacker identifies a Linux host or appliance that processes IPv4-over-IPv6 tunnel traffic through the ip6_tunnel/ip4ip6 path. The attacker sends crafted IPv6/tunnel-related traffic that reaches ip4ip6_err(), causing the kernel to process an error path and call icmp_send() on a cloned skb. Because the cloned skb retains IPv6 receive-path control-buffer contents, the IPv4 ICMP option-echo code misinterprets those bytes as IPv4 option metadata. The attacker arranges packet contents so that the misinterpreted option offset points into controlled packet data and supplies an oversized option length. __ip_options_echo() then copies that length into a fixed-size stack buffer, corrupting adjacent kernel stack memory. Depending on kernel build, mitigations, traffic path, and exploit reliability, this may produce a kernel panic, network-service outage, or potentially controlled kernel execution.

How to fix it

Upgrade to a Linux kernel version that includes the upstream fix for ip6_tunnel clearing skb->cb in ip4ip6_err() and validating the inner IPv4 header. Because no exact fixed package versions were provided, obtain fixed kernels from the relevant Linux distribution, appliance vendor, cloud image provider, or kernel stable branch advisory. After patching, reboot into the fixed kernel; merely installing the package is not sufficient if the host continues running the old kernel. Where immediate patching is not possible, reduce exposure by disabling unused IPv4-over-IPv6 tunnels, unloading or preventing use of the ip6_tunnel module where operationally safe, restricting IPv6 tunnel traffic to trusted peers, filtering unexpected IPv4-in-IPv6 and ICMPv6 error traffic at network boundaries, and placing tunnel endpoints behind ACLs or firewalls. Mitigations should be treated as temporary because the vulnerable code is in kernel networking and may be reachable before higher-level controls can inspect traffic.

How to confirm the fix worked

Confirm that each system is running a kernel build that contains the vendor fix, not only that an updated package is installed. Validate with uname -r, distribution package metadata, vendor security advisories, and kernel changelogs referencing the ip6_tunnel/ip4ip6_err skb->cb clearing fix. Check whether IPv4-over-IPv6 tunneling is in use by reviewing loaded modules, network interfaces, and tunnel configuration, for example with lsmod, modinfo, ip tunnel, ip -6 tunnel, and ip link. For exposure validation, confirm that untrusted networks cannot reach tunnel endpoints with IPv4-in-IPv6 protocol traffic or unexpected ICMPv6 errors. In a non-production lab only, regression testing should verify that malformed tunnel/error traffic no longer causes kernel oopses, panics, or traces involving ip4ip6_err(), icmp_send(), or __ip_options_echo().

Typical attack path

1. Locate Linux systems, routers, gateways, or appliances that accept or process IPv4-over-IPv6 tunnel traffic.
2. Send crafted IPv6 or IPv4-in-IPv6 tunnel-related traffic designed to trigger the ip4ip6_err() error-handling path.
3. Cause the kernel to clone an skb whose control buffer still contains IPv6 receive metadata.
4. Trigger icmp_send() and __ip_options_echo() so the stale IPv6 metadata is interpreted as IPv4 option metadata.
5. Use attacker-controlled packet bytes to influence the option length copied into the fixed 40-byte stack buffer.
6. Corrupt kernel stack memory, resulting in denial of service or potentially kernel-level code execution.

How to detect it

There are no reliable file-based indicators that prove exploitation, and successful exploitation may leave only crash artifacts or network telemetry. Review kernel logs, system journals, crash dumps, kdump/vmcore artifacts, and hypervisor or out-of-band management events for kernel oopses, panics, reboots, or stack traces involving ip4ip6_err(), ip6_tunnel, icmp_send(), or __ip_options_echo(). Correlate any crashes with inbound IPv6 tunnel traffic, IPv4-in-IPv6 packets, or ICMPv6 error traffic from untrusted sources. Network teams should examine flow logs, packet captures, IDS telemetry, and firewall logs for unexpected IPv6 next-header 4 traffic, unusual ICMPv6 error messages directed at tunnel endpoints, or spikes immediately preceding host instability. If threat hunting across historical logs, prioritize systems with configured IPv4-over-IPv6 tunnels, loaded ip6_tunnel modules, or unexplained reboots after receiving IPv6 tunnel/error traffic. Absence of these artifacts does not rule out exploitation, especially if logs were lost during a kernel crash.

• __ip_options_echo
• ip4ip6_err
• ip6_tunnel
• ip6_tnl
• icmp_send
• BUG: unable to handle kernel paging request
• kernel BUG at
• general protection fault
• Kernel panic - not syncing
• Oops:
• RIP: 0010:__ip_options_echo
• RIP: 0010:ip4ip6_err
• RIP: 0010:icmp_send
• IPv6 next header 4
• ip proto 4
• ICMPv6 Packet Too Big
• ICMPv6 Time Exceeded

What your security team should do

• Inventory Linux systems, appliances, routers, gateways, container hosts, and cloud images that run kernels with ip6_tunnel or IPv4-over-IPv6 tunneling support.
• Prioritize patching internet-facing or untrusted-network-facing tunnel endpoints first, followed by internal routing and virtualization infrastructure.
• Reboot systems after kernel updates and verify the active running kernel is the fixed version.
• Disable unused IPv4-over-IPv6 tunnel functionality and block unnecessary IPv4-in-IPv6 and ICMPv6 error traffic until patching is complete.
• Add monitoring for kernel oops, panic, and crash signatures referencing ip4ip6_err, ip6_tunnel, icmp_send, or __ip_options_echo.
• Review recent network telemetry for unusual IPv6 tunnel traffic or ICMPv6 error bursts targeting Linux tunnel endpoints.
• Because no KEV listing, ransomware use, or mature public exploit is reported, treat this as urgent for exposed tunnel infrastructure but risk-rank lower for systems that do not process IPv6 tunnel traffic.