CVE-2026-102715 in eclipse-threadx
Summary
by MITRE • 09/29/2026
Any host on the LAN can send two mDNS records and make the responder write past the end of its
transmit packet.
The string table stores each name in a slot rounded up to a multiple of four:
```c
/* addons/mdns/nxd_mdns.c:11436, 11443, 11447 */
memory_len = ((memory_len & 0xFFFFFFFC) + 8) & 0xFFFFFFFF;
...
len = *((USHORT*)(p - 2)); /* slot size, not string length */
if ((len == memory_len) && ... _nx_mdns_name_match(start, memory_ptr, memory_size) ...)
```
The lookup that decides whether an incoming name is already stored compares the rounded slot size,
so names of 12, 13, 14 and 15 characters share one bucket. A second name in the bucket is answered
with the pointer to the first, and the record then carries a string up to three bytes longer than
the length the caller accounted for. `_nx_mdns_packet_rr_add` (nxd_mdns.c:8911) sizes its only
bound check from that stale length, and `_nx_mdns_name_string_encode` writes the real string.
Two PTR records are enough, both ordinary mDNS responses to a `_http._tcp` query, with owner names
whose lengths fall in the same bucket:
```
==87491==ERROR: AddressSanitizer: heap-buffer-overflow
WRITE of size 1 at 0x611000000124 thread T5
#0 _nx_mdns_name_string_encode addons/mdns/nxd_mdns.c:13096 #1 _nx_mdns_packet_rr_add addons/mdns/nxd_mdns.c:8911
0x611000000124 is 0 bytes to the right of 228-byte region
```
The overflow is one to three bytes of attacker-influenced name data past `nx_packet_data_end`. In a
normal pool that lands in the next packet in the same pool rather than in a redzone, so the visible
effect is a corrupted neighbouring packet or a corrupted pool free list rather than a clean crash.
Compare the slot size against the stored string length before declaring a match, or keep the
string length in the slot header and return it to the caller so the encoder and the bound check
agree.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/29/2026
This vulnerability represents a heap-based buffer overflow within the mDNS responder implementation of the NetX Duo networking stack, specifically affecting how name lookups are performed and subsequent packet data is encoded. The core technical flaw stems from an inconsistency in length validation logic during string table management. When storing DNS names, the system allocates memory slots rounded up to multiples of four bytes for alignment purposes. However, when determining if a new incoming name already exists in the table, the comparison logic incorrectly uses this padded slot size rather than the actual original string length. This design oversight causes multiple distinct strings with lengths between twelve and fifteen characters to map to the same bucket or entry because their rounded sizes are identical.
The operational impact of this flaw is triggered when a host on the local area network sends two specific multicast DNS records, such as PTR records responding to an HTTP service query. Because these names fall into the same length bucket, the responder incorrectly identifies the second name as a duplicate of the first and returns a pointer to the existing entry without updating it with the new string's actual content or precise dimensions. Subsequently, when the system attempts to encode this record back into a packet using functions like _nx_mdns_packet_rr_add and _nx_mdns_name_string_encode, the bound check is calculated based on the stale, shorter length associated with the first name. Consequently, the encoder writes the full, longer string data past the allocated boundary of the current transmit packet buffer.
This out-of-bounds write results in a heap-buffer-overflow where attacker-influenced data overwrites memory immediately following the valid packet region. In typical pool-based memory allocation scenarios common in embedded systems, this overflow does not necessarily cause an immediate application crash due to redzone protections found in debug builds. Instead, it corrupts adjacent packets within the same memory pool or damages the free list metadata used for subsequent allocations. This corruption can lead to unpredictable network behavior, data leakage of sensitive information contained in neighboring buffers, or eventual denial of service through heap exhaustion and allocation failures when the corrupted metadata is eventually accessed during future packet processing cycles.
From a security classification perspective, this vulnerability aligns with CWE-120 Buffer Copy without Checking Size of Input and CWE-787 Out-of-bounds Write. In terms of attack vectors, it falls under MITRE ATT&CK technique T1496 Resource Hijacking if the corruption leads to resource exhaustion, or potentially T1530 Data from Cloud Storage if the corrupted memory contains sensitive network configuration data that is subsequently leaked through malformed responses. The vulnerability highlights a critical failure in input validation and state management within embedded networking stacks where performance optimizations like slot rounding were implemented without adequate safeguards for variable-length string handling.
Mitigation strategies must address both the immediate code defect and broader architectural assumptions regarding buffer safety. Developers should modify the name lookup logic to compare the actual stored string length against incoming names rather than relying on rounded slot sizes, ensuring that distinct strings are not erroneously treated as identical regardless of their true lengths. Alternatively, maintaining explicit string length metadata in the slot header would allow subsequent encoding functions to perform accurate bound checks before writing data. It is also advisable to implement strict bounds checking within _nx_mdns_name_string_encode to prevent any write operation from exceeding the allocated packet buffer limits, thereby containing potential overflows even if logical errors persist elsewhere in the stack.