CVE-2026-43083

What it actually does

This is a Linux kernel memory-safety flaw in the IPv6 IOAM6 tracing path. When an IPv6 IOAM trace packet has trace-type bit 6 set and the packet is being processed on the receive path, the kernel can use an ingress RX queue index as though it were a TX queue index for the egress device. If the ingress device has more RX queues than the egress device has TX queues, the index can exceed dev->num_tx_queues and access outside the dev->_tx[] array. The vulnerable path also lacked proper locking around qdisc queue-statistics access, creating a race condition between softirq and process contexts. Successful exploitation may cause kernel out-of-bounds memory access, kernel crash, denial of service, or exposure of kernel memory contents depending on build options, memory layout, and runtime conditions.

Why it matters to the business

Systems using affected Linux kernels with IPv6 IOAM6 functionality exposed can potentially be crashed remotely by crafted network traffic, causing service interruption for workloads, routers, appliances, or infrastructure nodes that process IPv6 IOAM packets. Because the issue is network-reachable, requires no authentication, and has a high CVSS score, it should be prioritized for kernel patching even though EPSS is currently low, stable over 30 days, not listed in CISA KEV, and has no known public exploit maturity. Organizations with Linux-based network appliances, container hosts, edge gateways, or systems that route or inspect IPv6 traffic should treat exposure as more urgent than ordinary local kernel bugs.

How an attack unfolds

An attacker first identifies a Linux system that processes IPv6 packets with IOAM6 tracing enabled or reachable through an IOAM-capable path. The attacker then sends crafted IPv6 traffic containing IOAM trace data with trace-type bit 6 set. During processing, the vulnerable kernel path calls into IOAM6 trace-data handling and derives a TX queue pointer from skb queue mapping. On the RX path, that mapping can reflect the ingress device RX queue rather than a valid egress TX queue. If the attacker can create or encounter a topology where the ingress device has more RX queues than the selected egress device has TX queues, the kernel can read outside the egress device transmit-queue array. Repeated or carefully timed packets may also interact with the missing qdisc statistics lock, increasing crash or instability likelihood. Practical exploitation is most likely to manifest as kernel oops, panic, or system hang; reliable memory disclosure would be environment-dependent and harder to verify from network observations alone.

How to fix it

Apply a vendor-supplied Linux kernel update that includes the upstream fix for the IOAM6 out-of-bounds access and missing locking issue. No exact fixed package versions were provided in the input, so use the relevant distribution or appliance vendor advisory for the patched kernel build. Prioritize internet-facing systems, IPv6 routers, edge devices, network appliances, Kubernetes/container hosts with IPv6 networking, and systems with CONFIG_IPV6_IOAM6_LWTUNNEL or IOAM6 functionality enabled. Where immediate patching is not possible, reduce exposure by disabling unused IPv6 IOAM6 functionality, blocking or rate-limiting IPv6 Hop-by-Hop Options and IOAM traffic at network boundaries where operationally safe, restricting IPv6 forwarding paths that do not require IOAM, and using kernel hardening features such as panic-on-oops policy appropriate to availability requirements, KASLR, slab freelist hardening, and crash dump collection. Mitigations should be treated as temporary because the correct fix is the patched kernel code that bounds-checks the TX queue index and adds the required locking.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel version matches a vendor release containing the fix, not just that an updated package is installed. Check with uname -r, package manager metadata, and the applicable distribution advisory. If kernel configuration is available, review /boot/config-$(uname -r) or /proc/config.gz for IOAM6-related options such as CONFIG_IPV6_IOAM6_LWTUNNEL to understand exposure. Validate network exposure by confirming whether IPv6 Hop-by-Hop Options and IOAM traffic are accepted, forwarded, or dropped according to policy. On test systems, use vendor-approved regression tests or packet-processing tests to confirm IOAM6 traffic no longer causes kernel warnings, KASAN reports, oopses, or panics. Review dmesg, journalctl -k, crash dumps, and monitoring for absence of new IOAM6-related kernel faults after the update.

Typical attack path

1. Identify Linux hosts, routers, appliances, or virtualized network nodes that process IPv6 traffic and may have IOAM6 support enabled.
2. Confirm that IPv6 Hop-by-Hop / IOAM-related traffic can reach the target processing path rather than being dropped at network boundaries.
3. Send crafted IPv6 IOAM trace packets with trace-type bit 6 set.
4. Trigger packet handling where the skb queue mapping originates from an RX queue index but is used against an egress device TX queue array.
5. Exploit a queue-count mismatch between ingress and egress devices to cause out-of-bounds access in the kernel IOAM6 path.
6. Repeat or time traffic to increase the chance of a kernel crash, panic, service disruption, or observable memory-safety failure.

How to detect it

There is no single definitive log entry proving exploitation; detection should combine network telemetry, kernel logs, and crash artifacts. Review firewall, IDS, packet-capture, and flow records for unusual IPv6 Hop-by-Hop Options or IOAM trace traffic, especially from untrusted sources or shortly before kernel crashes. Inspect kernel logs with dmesg, journalctl -k, rsyslog, audit logs, and centralized log platforms for oops, panic, KASAN, UBSAN, general protection fault, or page fault messages involving IOAM6 functions. Preserve and analyze vmcore/kdump artifacts from unexpected reboots to confirm whether the faulting stack includes __ioam6_fill_trace_data, skb_get_tx_queue, or qdisc_qstats_qlen_backlog. Correlate crash timing with network events involving IPv6 extension headers. If threat hunting at packet level is possible, search for IPv6 packets with Hop-by-Hop Options carrying IOAM trace options and trace-type bit 6 set. Because public exploitation is not currently known and EPSS is low, absence of these artifacts lowers suspicion but does not prove non-exploitation if logs or crash dumps were not retained.

• __ioam6_fill_trace_data
• skb_get_tx_queue
• qdisc_qstats_qlen_backlog
• ioam6
• BUG: KASAN: out-of-bounds
• KASAN: slab-out-of-bounds
• general protection fault
• kernel BUG at net/ipv6/ioam6
• net/ipv6/ioam6
• trace-type bit6
• IPv6 Hop-by-Hop Options
• IOAM trace option
• CONFIG_IPV6_IOAM6_LWTUNNEL
• panic: Fatal exception in interrupt
• Oops:

What your security team should do

• Inventory Linux systems that route, forward, inspect, or otherwise process IPv6 traffic, especially network appliances and edge systems.
• Prioritize patching systems with IOAM6 enabled or IPv6 Hop-by-Hop Options reachable from untrusted networks.
• Track distribution and appliance vendor advisories for the fixed kernel version because no exact fixed versions were provided.
• If patching must be delayed, block IPv6 IOAM and unnecessary Hop-by-Hop Options at perimeter and internal trust boundaries where safe.
• Enable or preserve kernel crash dump collection so suspected exploitation can be investigated after reboots or panics.
• Add monitoring for kernel logs referencing ioam6, __ioam6_fill_trace_data, skb_get_tx_queue, qdisc_qstats_qlen_backlog, KASAN out-of-bounds, general protection faults, or panic events.
• Do not rely on EPSS alone for prioritization; exploitation probability is currently low, but the vulnerability is unauthenticated, network-reachable, and potentially high-impact.
• After patching, verify the running kernel has changed and rebooted systems are no longer using the vulnerable kernel image.