CVE-2026-43341

What it actually does

This is a Linux kernel buffer overflow in the IPv6 IOAM6 trace handling path. The vulnerable code stores a schema-length contribution in an 8-bit value; with a large schema payload and a specific trace bit enabled, the value can wrap from 256 to 0. That bypasses the remaining-buffer-space check, after which the kernel copies the IOAM schema header and payload past the end of the trace buffer. Because the vulnerable path is in kernel networking code and the CVSS vector is network-accessible, unauthenticated, low-complexity, and no-user-interaction, successful exploitation could plausibly cause kernel memory corruption, denial of service, or potentially code execution with kernel privileges, depending on kernel build options, mitigations, and reachable IOAM configuration.

Why it matters to the business

Systems running affected Linux kernels may be exposed to remote kernel memory corruption through crafted IPv6 IOAM traffic. In practical business terms, this can lead to unexpected server crashes, degraded network reliability, service outages, and in the worst case compromise of the underlying host. The issue is not currently listed in CISA KEV, has no known public exploit maturity in the provided data, and has a low EPSS score, which lowers immediate exploitation likelihood; however, the high CVSS score and kernel-level impact make it important to remediate on internet-facing, IPv6-enabled, or IOAM-capable infrastructure.

How an attack unfolds

An attacker targets a Linux system that processes IPv6 IOAM6 trace data. They send specially crafted IPv6 packets containing IOAM trace information that enables the relevant schema-related trace bit and supplies a maximum-size schema payload. In vulnerable kernels, the schema length calculation wraps in an 8-bit variable, causing the kernel to believe there is enough space in the trace buffer. The write cursor is then positioned incorrectly, and the kernel copies the schema header and schema payload beyond the intended buffer boundary. The immediate outcome may be a kernel crash or packet-processing fault; with additional exploit development and favorable kernel conditions, the same corruption primitive could potentially be used to alter kernel memory and gain elevated control of the host.

How to fix it

Upgrade affected Linux kernels to a vendor-supported release that includes the upstream fix for the IOAM6 schema length wraparound in ioam6_fill_trace_data(). No exact fixed package versions were provided, so use distribution advisories from the relevant Linux vendor and confirm that the patch keeps the schema length in an unsigned int rather than an 8-bit value. Prioritize internet-facing, IPv6-enabled, routing, container-host, virtualization-host, and network-appliance systems. If immediate patching is not possible, reduce exposure by disabling IOAM6 functionality where not required, disabling IPv6 where operationally acceptable, and filtering untrusted IPv6 Hop-by-Hop / IOAM-related traffic at network boundaries. Treat filtering as a mitigation, not a replacement for patching.

How to confirm the fix worked

Confirm remediation by verifying the running kernel version against the Linux distribution’s security advisory or changelog for this issue. Ensure the active booted kernel, not only the installed package, contains the fix; reboot if required. Where source or patch metadata is available, validate that the IOAM6 trace fill code no longer stores the schema length in a u8 and that the remaining-space check uses the full schema length. Validate exposure reduction by confirming whether IPv6 and IOAM6 are enabled and whether boundary controls drop untrusted IPv6 Hop-by-Hop / IOAM traffic. For high-assurance environments, perform controlled negative testing in a lab with vendor-approved test cases or packet captures, not on production systems.

Typical attack path

1. Identify Linux hosts or network appliances that accept or process IPv6 traffic and may have IOAM6 functionality enabled or reachable.
2. Craft IPv6 traffic containing IOAM trace data with the schema-related trace bit enabled and a large schema payload that triggers the length wraparound condition.
3. Send the crafted packets to the vulnerable system over the network without needing authentication or user interaction.
4. Trigger the flawed remaining-space check in ioam6_fill_trace_data().
5. Cause __ioam6_fill_trace_data() to copy the schema header and payload beyond the trace buffer.
6. Leverage the result as a denial of service through kernel crash, or attempt further exploitation of kernel memory corruption if mitigations can be bypassed.

How to detect it

Look for evidence of attempted or successful exploitation in kernel logs, crash dumps, packet telemetry, and network device logs. Relevant sources include journalctl, /var/log/kern.log, /var/log/messages, dmesg output, kernel panic records, kdump/vmcore artifacts, EDR kernel-crash telemetry, NetFlow/IPFIX, firewall logs, IDS alerts, and packet captures involving IPv6 extension headers. Indicators include kernel oopses, panics, KASAN/KFENCE slab or stack out-of-bounds reports, general protection faults, or call traces referencing ioam6_fill_trace_data, __ioam6_fill_trace_data, IPv6 IOAM, or Hop-by-Hop option processing. Network-side detection should focus on unusual inbound IPv6 Hop-by-Hop traffic carrying IOAM trace data, especially repeated malformed or oversized IOAM schema payloads, spikes in IPv6 extension-header traffic, or packets that precede kernel crashes. Because reliable exploitation-specific byte patterns are not provided, detection should combine kernel fault artifacts with suspicious IPv6 IOAM traffic timing.

• ioam6_fill_trace_data
• __ioam6_fill_trace_data
• net/ipv6/ioam6
• IOAM6
• ioam6
• IPv6 IOAM
• Hop-by-Hop
• KASAN: slab-out-of-bounds
• KASAN: out-of-bounds
• BUG: KASAN
• kernel BUG
• general protection fault
• Oops:
• Kernel panic
• trace fill
• schema length
• schema payload

What your security team should do

• Inventory Linux systems that are IPv6-enabled, internet-facing, routing traffic, or performing network-observability functions where IOAM6 may be active.
• Prioritize patching of externally reachable Linux hosts and infrastructure systems because the flaw is remotely triggerable and affects kernel memory safety.
• Track Linux vendor advisories and deploy the first supported kernel version that includes the IOAM6 trace length fix; reboot systems into the fixed kernel.
• Temporarily block or restrict untrusted IPv6 Hop-by-Hop / IOAM-related traffic at perimeter and inter-segment controls where operationally feasible.
• Disable IOAM6 or IPv6 on systems that do not require it, following change-control and availability requirements.
• Monitor kernel logs and crash telemetry for IOAM6-related warnings, KASAN reports, general protection faults, panics, or unusual crashes in IPv6 packet-processing paths.
• Because the CVE is not in KEV and has low EPSS in the provided data, balance emergency response with exposure-based prioritization, but do not defer remediation on high-impact network-facing systems.