Vulnerability feed

The Web add-on's HTTP server dereferences and releases an uninitialized pointer when it detects a Content-Length underflow while processing a PUT request. The condition is reachable by an unauthenticated remote client with a single malformed request.

The X.509 parser in NetX Secure accepts an RSA public key of any size, but every signature-verification path decrypts into fixed-size buffers dimensioned for the NX_CRYPTO_MAX_RSA_MODULUS_SIZE default of 4096 bits. A certificate carrying a larger modulus drives an out-of-bounds write past a file-scope static during ordinary certificate-chain verification.

It is reachable pre-authentication. The issuer used for the crypto operation is looked up in the remote, peer-supplied store before the trusted store, so the attacker supplies the oversized key themselves as an intermediate in the chain they present. It triggers on a TLS or DTLS client verifying a malicious server's chain, and on a server performing client-certificate authentication.

The Web add-on's HTTP server searches the entire request packet for header fields instead of stopping at the end of the header section. A header field name placed in the request body is therefore reported to the server as though it were a header, which lets a client control request framing decisions it should not be able to reach.

The TLS 1.3 Certificate-message parser in NetX Secure decrements the message length to skip a context byte without first establishing that the message has a byte to skip. A zero-length Certificate message therefore wraps the unsigned length to 0xFFFFFFFF, which makes the bounds check that follows vacuous and sends the parser reading past the session packet buffer.

The trigger is a four-byte handshake header and requires no cryptographic validity. It is reachable pre-authentication.

A missing bounds check in the TLS 1.3 Certificate-message parser of NetX Secure lets a malicious TLS 1.3 server trigger an unsigned-integer underflow and a subsequent heap out-of-bounds read in any peer that processes a remote Certificate message. It is reachable pre-authentication, during the normal handshake, before certificate verification completes.

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 writes past it and on into the rest of 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 to reach it.

A DHCP server, or anyone on the LAN who answers a DISCOVER first, can make the client read about a

kilobyte past the end of the received message.

The option walk keeps a pointer and an offset in step, and the only bound check uses the offset:

/* addons/dhcp/nxd_dhcp_client.c:7538, 7572 */



while (i < length - 1)



{

    ...
    size = *(++data);      /* data moves 1: type -> length byte */
    data += size + 1;      /* data moves size + 1 more          */
    i += size + 1;         /* i moves only size + 1             */


}

A TLV option occupies size + 2 bytes. data is advanced by size + 2 in total, i by size + 1, so

the offset falls one byte behind the real read position for every option the walk skips. After

enough skipped options the check i < length - 1 still holds while data is already past the end

of the message, and the subsequent read of the type and length bytes comes from whatever follows.

A single OFFER carrying a long run of skippable options is enough:

ERROR: AddressSanitizer: heap-buffer-overflow



READ of size 1 at 0x61b000000794 thread T5

    #0 _nx_dhcp_search_buffer     addons/dhcp/nxd_dhcp_client.c:7541
    #1 _nx_dhcp_get_option_value  addons/dhcp/nxd_dhcp_client.c:7082


0x61b000000794 is located 164 bytes to the right of 1648-byte region

A well formed OFFER through the same path is handled normally, the client records the offer and

moves to REQUESTING, so the difference is the option layout rather than the harness.

The read runs in the DHCP client thread while the client is still unconfigured, so it happens on

every boot in reach of a hostile DHCP responder. The values read are used to configure the

interface, which is how the disclosed bytes become observable.

Advance i by size + 2, or derive the bound from data rather than keeping a second counter.

An unauthenticated client can drain the RTSP server's packet pool with a couple of dozen requests

that carry a Session header the parser cannot convert.

The Session branch returns the raw NetX error code instead of an RTSP status code:

/* addons/rtsp/nx_rtsp_server.c:2754 */



status = _nx_utility_string_to_uint(field_value_ptr, field_value_length, &session_id);



if (status)



{

    return(status);      /* NX_INVALID_PARAMETERS / NX_SIZE_ERROR / NX_OVERFLOW */


}

Every other branch of the same function maps its failure to an RTSP status first. The CSeq branch

eighteen lines earlier does exactly that (line 2736 returns NX_RTSP_STATUS_CODE_BAD_REQUEST). The

raw code then reaches _nx_rtsp_server_error_response_send (nx_rtsp_server.c:1234), which does not

recognise it, takes a path that returns without releasing the response packet it already allocated,

and the block never goes back to the pool.

Six requests with an empty Session header against a 22 packet pool:

valid requests:      after request 6: pool available = 21,  AFTER = 22 / 22



malformed requests:  after request 6: pool available = 16,  AFTER = 17 / 22

One block per request, not returned when the client disconnects. Twenty six requests take the pool

to zero and the server starts failing allocations, after which it serves nobody. If the pool is

shared with the rest of the application, as it is in the shipped sample, the rest of the stack

stops with it.

Convert the _nx_utility_string_to_uint failure in the Session branch into

NX_RTSP_STATUS_CODE_BAD_REQUEST the way the CSeq branch does, and release the response packet on

every exit path of _nx_rtsp_server_error_response_send.

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:

/* 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.