| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| 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). |
| 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. |
| `_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. |
| Buffer overflow in V8 in Google Chrome prior to 154.0.8037.92 allowed a remote attacker to execute arbitrary code inside the sandbox via a crafted HTML page. (Chromium security severity: High) |
| A stack-based buffer overflow vulnerability in the spamBlocker (spamd) service of WatchGuard Fireware OS allows an authenticated attacker with administrator privileges to crash the service or potentially execute arbitrary code by sending a specially crafted management request. |
| An integer underflow vulnerability in the WatchGuard Fireware OS IKE daemon (iked) allows a remote attacker who has completed the initial IKEv2 handshake to crash the iked process by sending a specially crafted encrypted IKEv2 message, resulting in a denial of service. |
| A stack-based buffer overflow vulnerability in WatchGuard Fireware OS's DHCP fingerprinting daemon (fingerd) allows an unauthenticated attacker with adjacent network access to execute arbitrary code or crash the process by sending a specially crafted DHCP packet. |
| 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. |
| 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. |
| Unbounded PPP IPCP Option Parsing Causes a Worker Stall and Out-of-bounds Read |
| 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. |
| Buffer overflow in Tint in Google Chrome on on Android prior to 154.0.8037.57 allowed a remote attacker to potentially execute arbitrary code outside the sandbox via a crafted HTML page. (Chromium security severity: High) |
| Buffer overflow in ANGLE in Google Chrome on on Android prior to 154.0.8037.92 allowed a remote attacker to potentially execute arbitrary code outside the sandbox via a crafted HTML page. (Chromium security severity: Critical) |
| Out of bounds read in WebGL in Google Chrome prior to 154.0.8037.92 allowed a remote attacker to read memory outside the sandbox via a crafted HTML page. (Chromium security severity: High) |
| 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. |
| Out-of-bounds Read from Unvalidated MSRP Attribute List Length |
| 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.) |
| Buffer overflow vulnerabilities exist in the affected interface of HPE Networking Instant ON APS that could allow an unauthenticated adjacent attacker to achieve remote code execution. Successful exploitation could allow an attacker to execute arbitrary commands on the underlying operating system. |
| Buffer overflow in ANGLE in Google Chrome on on Android prior to 154.0.8037.57 allowed a remote attacker to execute arbitrary code outside the sandbox via a crafted HTML page. (Chromium security severity: Critical) |
| Buffer overflow in ANGLE in Google Chrome on on Android prior to 154.0.8037.57 allowed a remote attacker to execute arbitrary code outside the sandbox via a crafted HTML page. (Chromium security severity: Critical) |
