CVE-2026-43038

What it actually does

This is a remote Linux kernel memory-corruption flaw in IPv6 ICMP error handling. A forged IPv4 ICMP error packet carrying a CIPSO IPv4 option can cause stale per-packet control-buffer data from an IPv4 packet to be interpreted as IPv6 metadata after the packet is cloned. That incorrect interpretation can make the kernel parse attacker-controlled inner IPv6 data at an attacker-influenced offset and potentially perform an out-of-bounds 16-byte operation near packet buffer metadata. The likely outcomes are kernel crash, denial of service, information exposure, or in worst-case conditions arbitrary kernel memory corruption with possible code execution. The issue is network-reachable, requires no authentication or user interaction, and is scored CVSS 9.8, although current EPSS is low and stable and no public exploit maturity or KEV listing is reported in the provided data.

Why it matters to the business

Systems running affected Linux kernels may be remotely crashed or potentially compromised by specially crafted network traffic. For organizations using Linux servers, appliances, containers backed by shared host kernels, network infrastructure, or IPv6/IPv4 transition paths, this can affect service availability and could create a route to full host compromise if exploitation becomes practical. The vulnerability has high theoretical severity but currently low observed exploitation probability: EPSS is approximately 0.0026 with no 30-day increase, it is not listed in CISA KEV, and it is not identified as ransomware-used in the provided data. Because Linux kernel fixes often propagate through downstream distributions and appliances at different speeds, asset owners should prioritize internet-exposed and network-edge Linux systems first while tracking vendor kernel advisories.

How an attack unfolds

An attacker sends a crafted IPv4 ICMP error packet to a vulnerable Linux system. The packet includes a CIPSO IPv4 option and encapsulates or references attacker-controlled IPv6 packet content. During ICMP error processing, the kernel clones the packet, but the cloned socket buffer retains control-buffer contents that were populated for IPv4 handling. The IPv6 ICMP path then interprets those same bytes as IPv6 control metadata. Because the IPv4 CIPSO option offset overlaps with the IPv6 destination Home Address Option offset field, the attacker can influence where the IPv6 parser starts scanning inside the inner packet. If parsing reaches a crafted or truncated option sequence, mip6_addr_swap() may operate beyond the valid packet data boundary and corrupt adjacent skb memory. Successful exploitation could cause an immediate kernel oops/panic or, with reliable heap shaping and kernel-specific conditions, could potentially be developed into privilege escalation or remote code execution in kernel context. No known public exploitation or named threat actor activity is provided, so defenders should treat this as a high-severity exposure with currently limited exploitation evidence.

How to fix it

Apply the Linux kernel update from the relevant distribution, appliance vendor, or kernel branch that includes the fix to clear the cloned skb control buffer in ip6_err_gen_icmpv6_unreach(). No exact fixed package versions were provided, so remediation should be tracked through vendor advisories for the specific Linux distribution and kernel stream in use. Reboot into the updated kernel after installation; installing a kernel package without rebooting does not remediate the running kernel. Where immediate patching is not possible, reduce exposure by filtering suspicious inbound IPv4 packets with IP options, especially CIPSO, at network boundaries where operationally safe; restrict ICMP error traffic to expected sources; block spoofed traffic with anti-spoofing controls; and limit exposure of IPv6-over-IPv4 transition or tunneling paths that are not required. Avoid blanket ICMP blocking without testing, because it can break path MTU discovery and legitimate network diagnostics.

How to confirm the fix worked

Confirm the running kernel, not just the installed package, is updated to a vendor build containing the fix. On Linux systems, compare `uname -r` and package manager output against the distribution advisory for this issue. Validate that a reboot occurred after the fixed kernel was installed. For source-built kernels, confirm the patch that clears `skb2->cb[]` in `ip6_err_gen_icmpv6_unreach()` is present. From a network-control perspective, verify edge firewalls, routers, or host firewalls log or block unexpected IPv4 packets with IP options/CIPSO where that mitigation is intended. In a lab only, use controlled packet-generation tests to ensure crafted ICMPv4 error packets with CIPSO options no longer crash the host and that malformed traffic is dropped or handled safely.

Typical attack path

1. Identify Linux systems reachable over IPv4 that process ICMP errors and have IPv6/IPv4-related packet handling paths enabled.
2. Craft an IPv4 ICMP error packet with IPv4 options, specifically a CIPSO option positioned to influence the overlapping control-buffer field.
3. Embed attacker-controlled IPv6 packet bytes so the IPv6 option parser can be directed to a chosen offset.
4. Send the forged packet to the target or to a network path where the vulnerable host will process it.
5. Trigger IPv6 ICMP unreachable generation, causing the cloned skb control buffer to be interpreted incorrectly as IPv6 metadata.
6. Force mip6_addr_swap() or related IPv6 option handling to operate past the valid packet boundary.
7. Cause kernel memory corruption, resulting in denial of service or potentially further exploitation depending on kernel version, configuration, and memory layout.

How to detect it

To assess possible prior exploitation, review network telemetry, packet captures, IDS alerts, firewall logs, and kernel crash artifacts. Look for inbound IPv4 ICMP error packets that contain IPv4 options, especially CIPSO, and that include embedded IPv6-looking payloads or malformed IPv6 destination options. NetFlow alone may not expose IP options, so full packet capture, IDS metadata, Zeek, Suricata, or firewall logs with IP-option visibility are more useful. On hosts, examine `dmesg`, `journalctl -k`, `/var/log/kern.log`, `/var/log/messages`, crash dumps, and kdump/vmcore records for kernel oops or panic traces involving IPv6 ICMP error handling, Home Address Option processing, skb memory corruption, or the functions named in the patch discussion. If kernel panics or unexplained reboots align with spikes in malformed ICMPv4 traffic, preserve packet captures and vmcores for forensic analysis. There are no provided named threat actors or campaigns, so detection should focus on protocol-level anomalies and kernel crash signatures rather than actor-specific infrastructure.

• ip6_err_gen_icmpv6_unreach
• icmp6_send
• mip6_addr_swap
• ipv6_find_tlv
• IP6CB
• skb_shared_info
• kernel BUG
• Oops:
• general protection fault
• BUG: unable to handle kernel paging request
• Kernel panic - not syncing
• IPv4 option 134
• CIPSO
• IP option CIPSO
• ICMP type 3
• ICMP type 11
• IPv6_TLV_HAO
• Home Address Option
• ip6ip6_err

What your security team should do

• Inventory Linux systems that are internet-facing, network-edge, or process untrusted IPv4/IPv6 traffic, and prioritize them for kernel updates.
• Track distribution and appliance vendor advisories because fixed versions were not provided in the input and may vary by downstream kernel branch.
• Patch and reboot high-exposure Linux hosts first, especially systems acting as routers, gateways, tunnel endpoints, load balancers, Kubernetes nodes, or virtualization/container hosts.
• Add temporary monitoring or filtering for inbound IPv4 ICMP error packets containing IPv4 options, particularly CIPSO option type 134, while confirming business impact before enforcement.
• Review firewall and router anti-spoofing controls to reduce delivery of forged ICMP error traffic.
• Search historical logs and crash dumps for kernel oops/panic traces involving `ip6_err_gen_icmpv6_unreach`, `icmp6_send`, `mip6_addr_swap`, or IPv6 destination option parsing.
• Enable packet capture or IDS visibility at exposed network edges for unusual ICMPv4 error traffic with embedded IPv6 content.
• Because EPSS is low, stable, and the issue is not in KEV, prioritize based on exposure and role rather than treating all Linux endpoints equally; however, do not defer patching on externally reachable infrastructure.