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.
- Published
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- How many real-world setups can hit the bug, from the vendor's advisory and CISA data. It does not know your setup.What do these mean? →
- Unclear
- Fix
- Fixed in 6.6.160, 6.12.114, 6.18.24, 6.19.14
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
- Exploitation: none
- Automatable: yes
- Technical impact: partial
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.
Summarized by anthropic/claude-haiku-5.5. Verify details against the original sources.
Read the original 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.
Timeline
- CVE published
- CISA SSVC assessment
Exploitation: none · Automatable: yes · Technical impact: partial
- Record last updated
Affected versions
- Linux Linux
Version range not reported
- Linux Linux
5.17
- KernelLinux
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
References 6
git.kernel.org
Questions about CVE-2026-43083
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: git.kernel.org
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: git.kernel.org
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: git.kernel.org
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: cve.now feed data