Frédéric Desbiens

The Module Manager loaders fail to release the Module Manager mutex when an overflow error occurs. This happens when a module preamble declares a data or stack size that causes an overflow during allocation arithmetic. Consequently, loading such an image blocks all subsequent module load, start, stop, and unload operations from other threads, requiring a system reset to recover.

When built with IPv6 path MTU discovery, the ICMPv6 Packet Too Big handler fails to verify if a destination-table entry was successfully added before using it. A remote attacker can flood the destination table with Packet Too Big messages containing new destinations. This leads to a NULL pointer dereference in the IP helper thread, causing the system to crash on targets that fault on address 0 and resulting in a complete stop of all network processing.

The PendSV handler of the Cortex-M module ports saves a preempted user-mode module thread's registers in privileged mode using addresses from the thread's stack pointer. Because the handler does not verify the pointer against the thread's stack, a memory-protected user-mode module can write up to nine words (eight of its choice, or 25 including floating-point state) into memory located immediately below any region it can write to, and subsequently read the stored data.

The Module Manager's thread-control services fail to verify if a thread provided by a user-mode, memory-protected module actually belongs to that module. This allows any loaded module to perform unauthorized actions on application threads or threads from other modules, including suspending, resuming, terminating, resetting, or re-prioritizing them, as well as aborting their waits. Such actions can lead to a denial of service or unauthorized changes to system scheduling.

The NetX Secure DTLS server allocates a session from its fixed session pool upon receiving the first datagram from an unrecognized address and port, occurring before the cookie exchange. Because sessions with stalled handshakes are never released, a remote, unauthenticated attacker can exhaust the session pool by sending one spoofed datagram per source. This leads to a denial of service for legitimate DTLS clients until the application resets the sessions.

When built with BSD raw socket and IPv6 support, the IPv6 raw send path fails to verify if a destination-table entry was successfully added. If the destination table is full and an off-link destination is accessed via a default router with an unknown neighbour cache entry, sending on an IPv6 raw socket with header inclusion causes a NULL pointer dereference. A remote sender can trigger this by filling the table, for instance, using ICMPv6 Packet Too Big messages, resulting in a crash of the sending thread.

In the IPv4 PASV path, the FTP Client accepts any address provided in the server's `227` reply. Because validation is limited to parsing and checking for non-zero values, a malicious server can specify an arbitrary address to redirect the Client.

A NULL pointer dereference occurs when the MSRP attribute table is exhausted. A NULL pointer dereference is a type of software error where a program attempts to read from or write to a memory address that is NULL, typically leading to a system crash.

A NULL pointer dereference occurs when evicting the sole MSRP (Media Service Resource Protocol) attribute. A NULL pointer dereference is a software error where the program attempts to read from or write to a memory address that is NULL, typically leading to a system crash.

Improper validation of non-secure (NS) pointers in multiple non-secure callable (NSC) entry functions allows an attacker in the non-secure world to provide pointers to secure memory. The secure firmware dereferences these pointers without verifying they reference non-secure memory, leading to the unintended disclosure of secure memory contents. This breach of isolation guarantees can be used as a memory disclosure or corruption primitive to potentially recover sensitive cryptographic material.

An issue exists where unbounded PPP IPCP option parsing leads to a worker stall and an out-of-bounds read. PPP (Point-to-Point Protocol) IPCP (Internet Protocol Control Protocol) is used to configure the IP addresses of two endpoints on a point-to-point link.

The issue involves an FTP passive data connection that is not bound to the authenticated control peer, which could allow an unauthorized party to intercept or hijack the data channel.

Two client-side TLS/DTLS handshake parsers contain bounded out-of-bounds reads. This occurs when the parsers read fields from a server-supplied message before validating if the message is long enough to contain them. The issue is triggered when a TLS or DTLS client connects to a malicious or malformed server; although a bounds check is present, it is executed after the read operation it is intended to protect.

An out-of-bounds read occurs due to the use of an unvalidated MSRP attribute list length. This issue allows the system to read data beyond the intended buffer boundaries when processing the attribute list.

In builds with `TX ENABLE EVENT TRACE` enabled, a user-mode, memory-protected module using `TXM MODULE USER MODE | TXM MODULE MEMORY PROTECTION` can register an arbitrary function pointer as the global trace-full callback. The kernel executes this pointer directly from privileged kernel code without validation or a trampoline when the trace buffer wraps. This can lead to a kernel fault resulting in a Denial of Service (DoS) if an invalid pointer is used, or allow code within the module to execute with kernel privileges (`CONTROL.nPRIV = 0`).

Two issues exist in the loadable-module loader. These are triggered when a device loads an attacker-controlled module object using the ` txm module manager memory load` or ` txm module manager in place load` APIs. Because these APIs only accept a base pointer and no image length, all size and offset fields in the `TXM MODULE PREAMBLE` are trusted. This leads to a heap out-of-bounds read, where the `code size` variable is trusted as the source-image length during the code-copy loop. Additionally, there is a control-flow-integrity gap where module entry, start, callback, and stop pointers are calculated as `code start + preamble offset` with only a non-zero check, and the preamble `checksum` is not verified.

The software generates predictable cookies during the DTLS HelloVerifyRequest process. This predictability can be exploited to bypass the cookie-based mechanism intended to prevent Denial of Service (DoS) attacks, which are attempts to make a machine or network resource unavailable to its intended users.

A heap-buffer-overflow occurs when a DHCP server or a malicious actor on the local area network responds to a DISCOVER message. The issue stems from an incorrect bound check during the option walk process, where a pointer and an offset are kept out of sync. Specifically, for every TLV (Type-Length-Value) option skipped, the offset falls one byte behind the actual read position. This allows the system to read approximately one kilobyte past the end of the received message if a long sequence of skippable options is provided in an OFFER message. This read operation occurs in the DHCP client thread during boot while the client is unconfigured, and the leaked bytes can be used to configure the interface, making the disclosed information observable. The flaw is located in the ` nx dhcp search buffer()` function, which is called by ` nx dhcp get option value()`.

A heap-buffer-overflow occurs when a TFTP server responds with a short ERROR packet. The client only verifies that the datagram is at least four bytes long, but fails to compare the `buffer ptr` against the `nx packet append ptr` when copying the message string. If an ERROR packet lacks a terminating NUL byte, the loop continues reading past the end of the packet until a zero byte is encountered or the 64-byte destination buffer is filled. This allows adjacent packet pool memory to be leaked into the `nx tftp client error string` variable, which may then be displayed or logged by the application. This issue affects the ` nxd tftp client file read()` function and other receive paths in the `nxd tftp client.c` file.