CVE-2026-43186

What it actually does

This is a Linux kernel heap buffer overflow in the IPv6 In-situ Operations, Administration, and Maintenance (IOAM) receive path. The vulnerable code trusts the IOAM trace nodelen value from an incoming IPv6 packet instead of validating it against the IOAM trace type bitmap that defines which trace fields are present. A malformed packet can declare an undersized node length while enabling many trace data fields, causing __ioam6_fill_trace_data() to write past the allocated packet buffer area and corrupt adjacent kernel heap memory, including skb-related metadata. The described observed outcome is a kernel panic, but because this is unauthenticated, network-reachable kernel memory corruption with a CVSS 9.8 rating, defenders should treat it as potentially capable of broader confidentiality, integrity, or availability impact until proven otherwise for their specific kernel build and configuration.

Why it matters to the business

Successful exploitation can crash affected Linux systems remotely, disrupting services that depend on those hosts, appliances, containers, routers, load balancers, or network functions. Because the flaw is reachable over the network without authentication or user interaction, internet-facing or untrusted-network-facing Linux systems with IPv6 and IOAM processing exposure carry the highest operational risk. It is not currently listed in CISA KEV, has no known ransomware association in the provided data, and the EPSS value is currently low and flat, but the severity remains high because exploitation could produce immediate outages at the kernel level.

How an attack unfolds

An attacker sends a crafted IPv6 packet containing an IOAM Hop-by-Hop option or related IOAM trace data that reaches the Linux kernel receive path. The packet sets the IOAM trace type bits to indicate that multiple trace fields are present, while setting nodelen to an inconsistent value such as zero. On a vulnerable kernel, the receive-side IOAM code uses the attacker-controlled nodelen to size or advance trace handling but then writes trace data based on the enabled type fields. This mismatch causes writes beyond the intended buffer boundary into adjacent kernel heap structures. The most likely visible result is a kernel panic and host reboot or crash, although kernel heap corruption vulnerabilities may have different outcomes depending on kernel version, configuration, hardening, and packet path.

How to fix it

Apply the Linux kernel update that includes the IOAM validation fix for __ioam6_fill_trace_data(), ioam6_trace_compute_nodelen(), ipv6_hop_ioam, and the corrected IOAM short-field mask handling. No exact fixed package versions were provided, so use the fixed kernel version from the relevant Linux distribution, appliance vendor, cloud image provider, or kernel long-term support branch. Prioritize externally reachable systems, network infrastructure, IPv6-enabled hosts, and systems that process Hop-by-Hop extension headers. Where immediate patching is not possible, reduce exposure by disabling or filtering IPv6 IOAM processing where supported, blocking untrusted IPv6 Hop-by-Hop extension headers at network boundaries, limiting IPv6 access to trusted peers, and using upstream firewall/router controls to drop malformed IOAM packets. Mitigations should be treated as temporary; kernel patching is the durable fix.

How to confirm the fix worked

Confirm the running kernel is a vendor-fixed build, not merely that an updated package is installed but not rebooted into. Validate with kernel package inventory, uname -a, distribution security advisories, and appliance firmware release notes. If source or custom kernels are used, confirm the receive path rejects IOAM trace packets when nodelen is inconsistent with the type bitmap and that the shared ioam6_trace_compute_nodelen() helper or equivalent validation is present. Review firewall/router policy to verify that untrusted IPv6 Hop-by-Hop IOAM traffic is filtered if mitigation is required. In test environments only, use a non-production validation tool or packet generator to confirm malformed IOAM packets are dropped without kernel warnings, panics, soft lockups, or slab corruption messages.

Typical attack path

1. Identify Linux systems or network appliances that accept IPv6 traffic and may process IOAM Hop-by-Hop options.
2. Send malformed IPv6 IOAM trace packets where the advertised node length is inconsistent with the trace type bitmap.
3. Trigger the vulnerable receive-path validation gap in the kernel IOAM handling code.
4. Cause out-of-bounds writes in kernel heap memory during IOAM trace data handling.
5. Achieve denial of service through kernel panic, crash, or instability; in worst-case scenarios, attempt to shape heap corruption for deeper compromise.

How to detect it

Look for evidence of exploitation primarily through host instability and malformed IPv6 IOAM traffic. Useful host log sources include kernel logs, systemd journal, crash dump facilities, kdump/vmcore repositories, console logs, hypervisor reset events, and EDR telemetry that records kernel panics or unexpected reboots. Network sources include Zeek, Suricata, IDS packet captures, router telemetry, NetFlow/IPFIX with IPv6 extension-header metadata, and firewall logs that record Hop-by-Hop option handling. Investigate Linux crashes or reboots preceded by inbound IPv6 packets containing Hop-by-Hop extension headers and IOAM options, especially malformed IOAM trace records where nodelen is zero or inconsistent with enabled type bits. On affected systems, look for kernel messages referencing skb corruption, heap/slab corruption, out-of-bounds writes, BUG/Oops reports, panic traces involving IPv6 extension-header processing, exthdrs.c, ioam6, ipv6_hop_ioam, or __ioam6_fill_trace_data(). Absence of logs does not rule out exploitation because a kernel panic can interrupt logging; preserve crash dumps and network telemetry around reboot times.

• __ioam6_fill_trace_data
• ipv6_hop_ioam
• ioam6
• exthdrs.c
• skb_shared_info
• kernel panic
• Kernel panic - not syncing
• BUG: kernel NULL pointer dereference
• BUG: unable to handle kernel paging request
• general protection fault
• slab-out-of-bounds
• KASAN: slab-out-of-bounds
• KASAN: use-after-free
• corrupted skb
• skb_over_panic
• IPv6 Hop-by-Hop
• Hop-by-Hop Options
• IOAM
• nodelen=0
• trace->nodelen
• inconsistent nodelen
• IPv6 extension header

What your security team should do

• Inventory Linux systems, appliances, and custom kernels that have IPv6 enabled and may process IOAM or IPv6 Hop-by-Hop extension headers.
• Patch affected kernels using vendor-provided updates and reboot systems into the fixed kernel; prioritize internet-facing, edge, routing, load-balancing, and multi-tenant systems.
• Until patching is complete, filter untrusted IPv6 Hop-by-Hop extension headers or IOAM option traffic at network boundaries where operationally safe.
• Increase monitoring for kernel panics, unexpected reboots, skb/slab corruption messages, and malformed IPv6 extension-header traffic.
• For custom kernels or embedded products, confirm the IOAM receive-path validation fix has been backported rather than relying on version string alone.
• Track vendor advisories for exact fixed versions because no per-package fixed versions were provided in the input.
• Because publication was 98 days ago, treat unpatched exposed systems as overdue for remediation even though KEV and EPSS do not currently indicate widespread exploitation.