Intelligence
Explorer.

An unprivileged, memory-protected ThreadX module can have the kernel read and write memory at addresses of its choosing, in privileged mode, and can use that to clear the MPU enable bit and remove its own isolation boundary. The Module Manager decided whether a privileged service could dereference an object address a module named by asking only whether that address fell outside the module. The manager's object pool is outside every module, so the test was satisfied by an address shifted into the interior of one of the module's own privileged allocations, which denotes no object at all. The bytes such an address presents as a control block are bytes the module put there through ordinary create and set services, so the control block ID at the front of them could be made to read as any type the module chose, and the `_txe_` layer's ID test then agreed. The reported chain uses that to reach a privileged `memset` across an attacker-chosen range.

Mounting an attacker-controlled NAND flash image (`lx_nand_flash_open()`) triggers an unbounded out-of-bounds heap **write** in LevelX's NAND flash-translation-layer metadata parser that overwrites a driver function pointer in the control block, giving a demonstrated control-flow hijack — RIP set to a full 8-byte attacker-chosen value (register-verified). Two accompanying OOB reads. All reproduced verbatim under ASan at HEAD `9f1cfdc`. (The affected metadata-parser header states "Some portions generated by Copilot (Sonnet 4.6)" — an AI-generated parser with an unchecked on-flash count.)

`gx_binres_theme_load()` sizes its theme buffer for the theme it was asked for, and allocates it even when the resource holds no theme with that id. A theme id at or past the theme count declared by the resource gets a buffer of zero bytes. The load pass then walks past the end of the theme table, takes whatever follows as a theme header, and writes a `GX_THEME` and its tables into that zero-byte buffer.

Two client-side TLS/DTLS handshake parsers in NetX Secure read fields from a server-supplied message before validating that the message is long enough to contain them. Both are bounded out-of-bounds reads on a remotely reachable path, both are reached from a TLS or DTLS client connecting to a malicious or malformed server, and both have the same shape: the bounds check exists and returns the correct status, but it runs after the read it is meant to guard.

FTP Passive Data Connection Not Bound to the Authenticated Control Peer

Unbounded PPP IPCP Option Parsing Causes a Worker Stall and Out-of-bounds Read

Out-of-bounds Read from Unvalidated MSRP Attribute List Length

NULL Pointer Dereference When Evicting the Sole MSRP Attribute

NULL Pointer Dereference on MSRP Attribute Table Exhaustion

In the IPv4 PASV path, the FTP Client accepts whatever address was sent in the server's `227` reply. Validation only covers the parse and the non-zero values, thus a malicious server can name any address and direct the Client there.

A TFTP server that answers with a short ERROR packet makes the client read up to 64 bytes past the received datagram. Each receive path checks only that the datagram is at least four bytes long (nxd_tftp_client.c:1229, 1521, 1984). When the opcode is NX_TFTP_CODE_ERROR the message string is copied with a loop whose only limits are the destination buffer and a NUL byte: ```c /* addons/tftp/nxd_tftp_client.c:1769 */ for (i = 0; (i < (sizeof(tftp_client_ptr -> nx_tftp_client_error_string) - 1)) && (*buffer_ptr); i++) ``` Nothing compares `buffer_ptr` against `nx_packet_append_ptr`. An ERROR packet that carries no terminating NUL, which a server controls completely, walks the loop off the end of the packet until it happens to meet a zero byte or fills the 64 byte destination. ``` ERROR: AddressSanitizer: heap-buffer-overflow READ of size 1 at 0x60d0000000c8 thread T4 #0 _nxd_tftp_client_file_read addons/tftp/nxd_tftp_client.c:1769 0x60d0000000c8 is 0 bytes to the right of 136-byte region ``` The open path has the same loop at :1327 and reports the same way. What is read lands in `nx_tftp_client_error_string`, which the application is expected to display or log, so adjacent packet pool memory ends up in whatever the device does with the error text. Add `(buffer_ptr < packet_ptr -> nx_packet_append_ptr)` to the loop condition in all three paths.

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: ```c /* 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.

Predictable DTLS HelloVerifyRequest Cookie in NetX Secure

hey, `_nx_snmp_utility_object_id_get` in the NetX Duo SNMP addon does not validate the claimed OID data length against the actual buffer size when the OID uses BER multibyte length encoding, so a remote attacker can send a crafted SNMP packet with a multibyte OID length larger than the available buffer, causing the parser to read past the packet buffer boundary into adjacent heap memory. the OOB bytes are decoded as OID component values and written into the agents internal OID string buffer, corrupting agent state. on systems with memory protection the OOB read poses the risk of crashing the SNMP agent thread, causing denial of service. on bare metal embedded systems without memory protection the read silently succeeds and corrupts the agents internal state with heap data.

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: ```c /* 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: ```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.

`_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.

The TFTP server accepts a DATA datagram of any size. The dispatcher rejects datagrams shorter than four bytes (nxd_tftp_server.c:1037) and nothing anywhere checks an upper bound, in particular not against the protocol maximum of 4 + NX_TFTP_FILE_TRANSFER_MAX. Two things follow from that one missing check, both reachable before any authentication because TFTP has none. The handler passes `nx_packet_length - 4` straight to FileX: ```c /* addons/tftp/nxd_tftp_server.c:1863, 1889 */ status = nx_packet_copy(packet_ptr, &temp_ptr, server_ptr -> nx_tftp_server_packet_pool_ptr, NX_WAIT_FOREVER); ... fx_file_write(&(client_request_ptr -> nx_tftp_client_request_file), packet_ptr -> nx_packet_prepend_ptr + 4, packet_ptr -> nx_packet_length - 4); ``` `nx_packet_length` is the length of a chain, not of one contiguous buffer, so FileX copies past the end of the first packet: ``` ERROR: AddressSanitizer: heap-buffer-overflow READ of size 1280 at 0x621000001108 thread T5 #0 __interceptor_memcpy #1 _fx_utility_memory_copy filex/common/src/fx_utility_memory_copy.c:78 0x621000001108 is 0 bytes to the right of 4104-byte region ``` Those bytes are written into the file the attacker is uploading, and a TFTP read request hands them back, so this is a memory disclosure with a convenient retrieval channel. The same datagram also wedges the server. `nx_packet_copy` at :1863 needs ceil(nx_packet_length / pool_payload) packets and asks for them with NX_WAIT_FOREVER, so when the attacker sizes the datagram beyond what the pool holds, the server thread suspends and never returns. A liveness probe after one such datagram times out with the pool at 0 of 12 packets and the server thread suspended, and no later client is served. Reject `nx_packet_length > 4 + NX_TFTP_FILE_TRANSFER_MAX` in the DATA branch before either call, and use a bounded wait rather than NX_WAIT_FOREVER for the copy.

On the first DTLS ClientHello, the parser copies a device-claimed session_id length and validates the ciphersuite-list length against the total record length instead of the remaining bytes. An unauthenticated peer drives an OOB source read of up to 255 bytes, and those bytes are echoed verbatim into the outgoing ServerHello, disclosing adjacent process memory over the network. The crash variant fires on the first packet.

Two issues in the ThreadX loadable-module loader, reached when a device loads an attacker-controlled module object via `_txm_module_manager_memory_load` / `_txm_module_manager_in_place_load` — APIs that take ONLY a base pointer, no image length, so every size/offset field in `TXM_MODULE_PREAMBLE` is fully attacker-trusted: (1) a heap OOB **read** (`code_size` trusted as the source-image length in the code-copy loop), and (2) a control-flow-integrity / defense-in-depth gap (module entry/start/callback/stop pointers computed as `code_start + preamble_offset` with only a `!= 0` check, and the preamble `checksum` never verified). No controlled OOB write was found (honest — the copy destination is overflow-guarded).

Attacker model / Preconditions: a loaded `TXM_MODULE_USER_MODE | TXM_MODULE_MEMORY_PROTECTION` module issuing kernel dispatch calls, on a build with `TX_ENABLE_EVENT_TRACE`. A user-mode, memory-protected module can register an arbitrary function pointer as the global trace-full callback. The kernel calls it directly — no validation, no trampoline — from privileged kernel code when the trace buffer wraps. An invalid pointer faults the kernel (DoS). A pointer into the module's own code was observed running with kernel privilege (`CONTROL.nPRIV = 0`), confirmed at runtime with a register capture inside that code.

Improper validation of non-secure (NS) pointers in multiple TrustZone-M non-secure callable (NSC) entry functions allows an attacker executing in the non-secure world to supply pointers to secure memory. The secure firmware subsequently dereferences these attacker-controlled pointers without verifying that they reference non-secure memory, resulting in unintended disclosure of secure memory contents. This violates the isolation guarantees provided by Arm TrustZone-M and can be leveraged as a memory disclosure or corruption primitive that may enable recovery of sensitive cryptographic material.

Electron is a framework for writing cross-platform desktop applications using JavaScript, HTML and CSS. From 42.3.3 until 42.10.0, 43.5.0, and 44.0.0-beta.6, Electron's sandboxed preload code cache did not verify that a cached entry matched the preload it was served for. A compromised renderer could write attacker-controlled cache data and cause Electron to reuse it for a later load, executing the renderer's code in the more privileged preload context. The issue affects applications that load untrusted content. This issue is fixed in versions 42.10.0, 43.5.0, and 44.0.0-beta.6.

MobilityDB version 1.3.0 and earlier contains an out-of-bounds read vulnerability in the MEOS binary and library WKB deserialization logic that allows unprivileged database users to crash the PostgreSQL backend process by supplying a crafted WKB payload with a negative length field. The negative length value wraps to a large unsigned size_t due to missing signed validation, bypasses an overflow-unsafe pointer arithmetic bounds check in wkb_parse_state_check(), and causes memcpy() in text_from_wkb_state() to operate with a corrupted unbounded length, resulting in a remote denial-of-service condition affecting all sessions on the PostgreSQL instance.