CVE-2026-43101

What it actually does

This vulnerability is a NULL pointer dereference in the Linux kernel IPv6 IOAM code path, specifically in __ioam6_fill_trace_data(). When IPv6 In-situ Operations, Administration, and Maintenance (IOAM) trace data is processed or generated, the kernel may fail to validate that the IPv6 device context returned by __in6_dev_get() is present before dereferencing it. A remote, unauthenticated attacker may be able to trigger this condition with network traffic that reaches an affected host or router using the vulnerable IPv6 IOAM path, causing a kernel oops or panic and resulting in denial of service. The issue affects availability only; it does not directly provide confidentiality loss, integrity modification, or code execution based on the published description.

Why it matters to the business

Successful exploitation can crash affected Linux systems or networking nodes, interrupting applications, routing, packet forwarding, appliances, containers, or services that depend on the vulnerable kernel. The CVSS score indicates high availability impact and the attack vector is network-accessible, but current public risk signals are lower: it is not listed in CISA KEV, is not reported as used in ransomware campaigns, has low EPSS, and no mature public exploit is indicated. Organizations using IPv6 IOAM or exposing Linux systems to IPv6 extension-header traffic should still prioritize patching because a crash in a shared kernel can affect many workloads at once.

How an attack unfolds

An attacker first identifies a reachable Linux system or network device running an affected kernel with IPv6 enabled and with traffic capable of entering the IOAM-related IPv6 processing path. The attacker then sends crafted IPv6 traffic, likely involving IOAM or Hop-by-Hop extension-header behavior, that causes the kernel to execute __ioam6_fill_trace_data(). In the vulnerable implementation, the kernel assumes the IPv6 per-device state exists and dereferences it without sufficient NULL checks. If the required state is absent or races with device state changes, the dereference can trigger a kernel fault. Depending on kernel panic settings and system configuration, this may crash the kernel immediately, produce an oops while disrupting networking, or force a reboot. There is no indication that exploitation grants code execution or privilege escalation; the realistic outcome is service disruption.

How to fix it

Upgrade the Linux kernel to a vendor-provided fixed release for the affected distribution or appliance. Because no exact fixed versions were provided in the input, use the relevant Linux distribution, cloud image, container host, or appliance security advisory to identify the patched kernel package. After installation, reboot or live-patch as supported so the running kernel is actually replaced. If immediate patching is not possible, reduce exposure by disabling IPv6 IOAM where it is not required, removing IOAM route or tunnel configuration, limiting IPv6 Hop-by-Hop and IOAM extension-header traffic at network boundaries, and restricting untrusted IPv6 traffic to systems that do not need to process it. Avoid relying only on package installation status; the vulnerable kernel remains active until the system boots or switches into the fixed kernel.

How to confirm the fix worked

Confirm the running kernel version and build are covered by the vendor advisory, not just that an updated package is installed. On Linux systems, compare uname -a and package-manager output against the distribution’s fixed kernel release. Validate that hosts have rebooted into the fixed kernel or that an applicable live patch is active. Review IPv6 IOAM configuration with platform-appropriate tools, such as route, tunnel, and IOAM namespace/schema configuration commands, and confirm IOAM is disabled or constrained where not required. From the network side, verify whether IPv6 Hop-by-Hop/IOAM traffic is filtered according to policy. For high-assurance validation, reproduce only in a controlled lab with crash-safe test systems; do not send malformed extension-header traffic to production systems as a test.

Typical attack path

1. Identify Linux hosts, routers, appliances, or container platforms reachable over IPv6.
2. Determine whether IPv6 extension-header traffic can reach the target and whether IOAM-related processing may be enabled or reachable.
3. Send crafted IPv6 packets that exercise the IOAM trace-data fill path.
4. Trigger a NULL pointer dereference in __ioam6_fill_trace_data().
5. Cause a kernel oops, panic, reboot, or loss of network availability.
6. Repeat traffic to maintain denial of service until the host is patched or traffic is filtered.

How to detect it

To determine whether this was already exploited, examine persistent kernel logs, system journals, crash dumps, netconsole output, remote syslog, and monitoring alerts for kernel oops or panic events involving __ioam6_fill_trace_data, IOAM6, IPv6 extension headers, or NULL pointer dereferences. Look for unexplained reboots or node outages correlated with inbound IPv6 traffic, especially Hop-by-Hop extension-header traffic or IOAM-related packets. Network telemetry may show spikes in IPv6 packets with Hop-by-Hop options shortly before a crash. Because a kernel panic can erase local volatile logs, prioritize centralized logging, kdump/vmcore analysis, hypervisor reset logs, BMC/iDRAC/iLO event logs, and network flow records around the time of outage. There are no named threat actors or ransomware campaigns reported for this issue in the provided data, and no public exploit maturity is indicated, so detection should focus on crash artifacts and suspicious IPv6 extension-header traffic rather than known attacker infrastructure.

• __ioam6_fill_trace_data
• BUG: kernel NULL pointer dereference
• kernel NULL pointer dereference
• RIP: 0010:__ioam6_fill_trace_data
• Oops: 0000
• Kernel panic - not syncing
• ioam6
• IOAM6
• IPv6: IOAM
• ipv6 ioam
• skb_dst_dev_rcu
• __in6_dev_get
• ip -6 route show | grep -i ioam
• ip ioam namespace show
• ip ioam schema show
• IPv6 Hop-by-Hop Options
• nexthdr hopopt

What your security team should do

• Inventory Linux systems, routers, appliances, hypervisors, and container hosts that run affected kernels and have IPv6 enabled.
• Prioritize patching systems that process untrusted IPv6 traffic, perform routing/forwarding, use IOAM, or host many workloads on a shared kernel.
• Apply the vendor-fixed kernel and reboot or activate live patching so the running kernel is no longer vulnerable.
• If patching is delayed, disable unused IPv6 IOAM functionality and filter unnecessary IPv6 Hop-by-Hop/IOAM extension-header traffic at boundaries.
• Monitor for kernel crashes, unexpected reboots, and logs referencing __ioam6_fill_trace_data or IPv6 IOAM processing.
• Ensure crash dumps, persistent journald logs, netconsole, or remote syslog are enabled on critical Linux infrastructure so exploitation attempts are not lost during reboot.
• Track vendor advisories for exact fixed kernel versions because upstream and downstream distribution version numbers may differ.