CVE-2026-102714
HighCVSS 7.1Summary
The `_nx_icmpv6_validate_options()` function in the Eclipse ThreadX (NetX Duo) network stack scans the ICMPv6 option area with `while (length > 2)`, leaving a one- or two-byte tail unexamined and returning `NX_SUCCESS`. Consumers then re-walk the same area, reading a two-byte option header at the residue and subtracting `nx_icmpv6_option_length << 3` with no zero check and no remaining-length check. This yields three outcomes: an infinite loop (zero length byte), unsigned counter underflow and out-of-buffer reads (non-zero length byte on a short residue), and a one-byte over-read (one-byte residue).
Risk Assessment
An attacker can remotely send crafted ICMPv6 packets to hang the system until a watchdog reset (replayable after each reset) or cause out-of-bounds reads where stray bytes are copied into the neighbor cache and used as the destination MAC, potentially leaking memory or injecting traffic. The vulnerability affects the highest-priority IP thread, so a hang stops the entire system.
Recommendation
Update Eclipse ThreadX / NetX Duo to a version containing the fix for CVE-2026-102714. Until patched, consider restricting ICMPv6 processing to necessary interfaces or filtering ICMPv6 traffic at the network edge.
Other vulnerabilities in Eclipse ThreadX NetX Duo
See all- CVE-2026-103416Critical
Out-of-bounds write via the TLS 1.3 handshake message cache in NetX Duo in Eclipse ThreadX NetX Duo 6.5.1.202602 allows a handshake message larger than the cache to write past it and into the session control block, which holds pointers. A malicious or compromised server can make a TLS 1.3 client produce such a message before certificate authentication completes, so no server certificate is needed.
- CVE-2026-11576High
The security fix for CVE-2025-0728 in eclipse-threadx NetX Duo introduced a new vulnerability. The shared cleanup path in the HTTP server PUT process calls fx_file_close() even when the file was never opened, leading to undefined behavior, double-close issues, or memory corruption.
Original NVD description (English source)
`_nx_icmpv6_validate_options()` scans the option area with `while (length > 2)` (`common/src/nx_icmpv6_validate_options.c:79`). An area whose size leaves a one- or two-byte residue exits the loop with that tail unexamined; the residue is not negative, so the function returns `NX_SUCCESS`. Its zero-length rejection never sees those bytes. Every consumer then re-walks the same area, reading a two-byte option header at the residue and subtracting `nx_icmpv6_option_length << 3` with no zero check and no remaining-length check. Three outcomes follow, selected by bytes the attacker controls. **Zero length byte.** The walker subtracts zero and advances zero. All four handlers loop forever — `_nx_icmpv6_process_ra` (`nx_icmpv6_process_ra.c:245, :528`), `_nx_icmpv6_process_ns` (`:251, :329`), `_nx_icmpv6_process_na` (`:147, :156`) and `_nx_icmpv6_process_redirect` (`:247, :350`). The walk runs in the IP thread, which is the highest-priority thread and does not yield inside the loop, so the system stops until a watchdog reset and the frame can be replayed after each one. **Non-zero length byte on a short residue.** The three unsigned counters underflow — `2 - 8` becomes `0xFFFFFFFA` — and the walk continues past the packet buffer, reading until it faults or meets a zero length byte and freezes. The Router Advertisement counter is signed and exits cleanly in this case. **One-byte residue.** The walker reads a two-byte option header, over-reading one byte. During a runaway walk, stray bytes parsing as a link-layer address option are copied into the neighbor cache (`nx_icmpv6_process_ns.c:280, :293`) and subsequently used as the destination MAC for frames to that neighbour, placing off-packet memory on the link. Confirmed by inspection, not reproduced.
Vulnerability data from NVD (NIST) · CISA KEV · EPSS

