Adawn0106

Mounting an attacker-controlled FAT image with fault tolerance enabled causes an out-of-bounds heap write during log replay. The write is attacker-positioned and attacker-valued, and on a common embedded memory layout it reaches the FX MEDIA driver callback, giving control of the instruction pointer.

A HID report descriptor is a sequence of items, each declaring in its header how many data bytes follow. The USBX host walks that sequence by advancing over each header and parsing the data behind it. The walk checked that an item fitted in the descriptor only **after** it had advanced past the header and parsed the payload, and the item analysis it relied on never measured the declared sizes against the bytes actually received. A HID peripheral returning a short report descriptor therefore drove a heap out-of-bounds read during ordinary enumeration.

The GUIX binary resource loader never checks that a font page's glyph range is well formed. `gx page header first glyph` and `gx page header last glyph` are read verbatim from the file and only the upper bound of `last glyph` is validated, so a page declaring `first glyph > last glyph` makes `last - first + 1` underflow to a very large unsigned count. That count is multiplied by a glyph record size to reserve the load buffer, and the multiply is unchecked, so it wraps to a small value and the loader allocates a buffer far smaller than the data it is about to write. The load pass then recomputes the count in a narrower type and writes attacker-controlled glyph records into the undersized buffer.

`gx binres theme load()` and `gx binres font load()` take the resource as a bare `GX UBYTE *` with no length, and `GX BINRES DATA INFO` has no field to carry one. Every read is therefore performed at an offset the file itself chose, against a buffer whose extent the loader does not know. A resource that declares more data than it contains is read past its end, and an offset stored in the file is turned into a pointer without being bounded. This is a distinct defect from GHSA-hgcj-22cg-4hfv, which was an underflowed glyph count. It needs no underflow and no wrapped multiply: a perfectly well-formed, narrow glyph range reaches it.

**Name of the Vulnerable Software and Affected Versions** NetX Duo (affected versions not specified) **Description** The MQTT client fails to release the packet containing a malformed PUBLISH message. This results in a memory leak where each malformed message consumes a packet or a chain of packets from the network driver's receive pool without returning it. An attacker can exhaust the receive pool by sending a small number of these messages, which halts all inbound network traffic on the device until a reboot is performed. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** ThreadX (affected versions not specified) **Description** 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. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** LevelX (affected versions not specified) **Description** Mounting an attacker-controlled NAND flash image via the `lx nand flash open()` function triggers an unbounded out-of-bounds heap write within the NAND flash-translation-layer metadata parser. This occurs because the parser, which contains AI-generated portions, fails to check the on-flash count. The flaw allows an attacker to overwrite a driver function pointer in the control block, leading to a control-flow hijack where the Instruction Pointer (RIP) can be set to an attacker-chosen 8-byte value. Additionally, two out-of-bounds reads are present. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** The product name cannot be determined (affected versions not specified) **Description** 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. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** The product name cannot be determined (affected versions not specified) **Description** During the first DTLS ClientHello, the parser copies a device-claimed `session id` length and validates the ciphersuite-list length against the total record length rather than the remaining bytes. This allows an unauthenticated peer to trigger an Out-of-Bounds (OOB) source read of up to 255 bytes. These bytes are then echoed verbatim into the outgoing ServerHello, resulting in the disclosure of adjacent process memory over the network. A variant of this issue can also cause a crash upon receiving the first packet. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** NetX Duo SNMP addon (affected versions not specified) **Description** The ` nx snmp utility object id get` function in the NetX Duo SNMP addon fails to validate the claimed OID data length against the actual buffer size when Basic Encoding Rules (BER) multibyte length encoding is used. A remote attacker can send a crafted SNMP packet with a multibyte OID length that exceeds the available buffer, causing the parser to perform an out-of-bounds read into adjacent heap memory. These bytes are then decoded as OID component values and written into the agent's internal OID string buffer, leading to state corruption. On systems with memory protection, this can crash the SNMP agent thread and cause a denial of service, while on bare metal embedded systems without memory protection, the read may silently corrupt the internal state with heap data. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** NetX Duo (affected versions not specified) **Description** The WebSocket client incorrectly resets the unmasking cursor to the first `NX PACKET` when advancing through a chained packet, while the loop's upper bound remains tied to the current packet. In a standard contiguous packet-pool layout, a masked server frame split across two packets causes the XOR loop to write through the first packet's unused payload area and into the second packet's `NX PACKET` control block. Because the four-byte WebSocket masking key controls the bytes written, this allows for attacker-chosen memory corruption. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.