Linux Kernel CVE-2026-43083

Exploitation requires specific network configuration and kernel features: the target system must run Linux kernel version 5.17 or later with CONFIG_IPV6_IOAM6_LWTUNNEL enabled (IOAM6 support compiled into the kernel), the system must actively process IPv6 packets as a forwarding node or router with IOAM6 trace handling configured, attacker-controlled packets must traverse from an ingress network device with more RX queues to an egress device with fewer TX queues (e.g., from a 10GbE NIC with 16 RX queues to a 1GbE NIC with 4 TX queues), and the crafted IPv6 packets must include Hop-by-Hop extension headers with IOAM trace type bit 6 set. This is NOT default configuration exploitation - IOAM6 is a specialized feature rarely enabled outside of service provider networks or research environments conducting active network telemetry. The multi-queue device topology requirement further limits real-world attack surface. Systems not explicitly configured for IOAM6 monitoring or not forwarding IPv6 packets between interfaces with mismatched queue counts are not exploitable despite running vulnerable kernel versions.

The CVSS score of 9.1 (Critical) reflects network-based remote exploitation (AV:N) with low complexity (AC:L) requiring no authentication (PR:N) or user interaction (UI:N), enabling high confidentiality impact (C:H) and high availability impact (A:H). However, real-world risk assessment reveals significant mitigating factors. The EPSS score of 0.02% (4th percentile) indicates extremely low probability of exploitation in practice, suggesting this vulnerability requires highly specific conditions. Exploitation depends on precise network topology: the attack succeeds only when IPv6 IOAM6 trace processing is enabled AND packets traverse from high-RX-queue-count ingress devices to low-TX-queue-count egress devices AND the specific IOAM trace type bit 6 is set. Most production environments do not deploy IOAM6 tracing, which is primarily used in controlled research and service provider monitoring scenarios. The vulnerability is not present in CISA KEV, confirming no observed active exploitation. The confidentiality impact allows reading kernel memory contents from the out-of-bounds access, potentially leaking addresses useful for KASLR bypass, while the availability impact stems from potential kernel crashes. The missing lock issue presents lower immediate risk but could enable denial-of-service through race-induced panics. Patches are available across stable kernel branches (5.17+, 6.18.24, 6.19.14, 7.0), significantly reducing exposure for actively maintained systems. Priority should be moderate for systems explicitly using IOAM6 features, low for standard deployments where the code path is unused.

An attacker crafts malicious IPv6 packets containing IOAM trace options with type bit 6 set and sends them to a vulnerable Linux system acting as an IPv6 router or forwarding node. The attacker controls the ingress network interface topology to ensure packets arrive on a high-queue-count interface then get forwarded through a lower-queue-count egress interface. When the kernel's __ioam6_fill_trace_data() function processes these packets, the skb->queue_mapping value exceeds the dev->num_tx_queues boundary, causing skb_get_tx_queue() to access memory beyond the dev->_tx[] array. The attacker can trigger repeated out-of-bounds reads to extract kernel memory contents including potentially sensitive data structures or addressing information useful for further exploitation, or cause kernel crashes leading to denial of service. Since IOAM6 processing occurs during normal packet forwarding, no authentication is required and exploitation is possible from remote network positions.