🚨 CVE-2026-102713
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.
🎖@cveNotify
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.
🎖@cveNotify
🚨 CVE-2026-102714
`_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.
🎖@cveNotify
`_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.
🎖@cveNotify
🚨 CVE-2026-102715
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.
🎖@cveNotify
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.
🎖@cveNotify
🚨 CVE-2026-102716
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`.
🎖@cveNotify
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`.
🎖@cveNotify
🚨 CVE-2026-102718
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.
🎖@cveNotify
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.
🎖@cveNotify
🚨 CVE-2026-102720
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.
🎖@cveNotify
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.
🎖@cveNotify
🚨 CVE-2026-102721
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.
🎖@cveNotify
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.
🎖@cveNotify
🚨 CVE-2026-102722
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.
🎖@cveNotify
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.
🎖@cveNotify
🚨 CVE-2026-102726
Unbounded PPP IPCP Option Parsing Causes a Worker Stall and Out-of-bounds Read
🎖@cveNotify
Unbounded PPP IPCP Option Parsing Causes a Worker Stall and Out-of-bounds Read
🎖@cveNotify
🚨 CVE-2026-102728
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.
🎖@cveNotify
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.
🎖@cveNotify
🚨 CVE-2026-102729
`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.
🎖@cveNotify
`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.
🎖@cveNotify
🚨 CVE-2026-102730
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.)
🎖@cveNotify
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.)
🎖@cveNotify
🚨 CVE-2026-102757
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.
🎖@cveNotify
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.
🎖@cveNotify
🚨 CVE-2026-102758
The `_nx_secure_x509_asn1_tlv_block_parse()` function parses ASN.1 TLV (tag-length-value) blocks out of DER-encoded data. It is the primitive underneath all X.509 certificate parsing in NetX Secure, and therefore runs on certificates supplied by a remote peer during the TLS handshake.
The function reads the one-byte ASN.1 tag from the caller's buffer *before* checking that the buffer holds at least one byte. When a caller passes a remaining length of zero, the guard correctly returns `NX_SECURE_X509_ASN1_LENGTH_TOO_LONG`, but the read has already happened one byte past the end of the buffer.
code:
nx_secure/src/nx_secure_x509_asn1_tlv_block_parse.c
```
UINT _nx_secure_x509_asn1_tlv_block_parse(const UCHAR *buffer, ULONG *buffer_length, USHORT *tlv_type,
USHORT *tlv_tag_class, ULONG *tlv_length,
const UCHAR **tlv_data, ULONG *header_length)
{
UINT current_index;
USHORT current_tag;
ULONG length;
ULONG length_bytes;
current_index = 0;
current_tag = buffer[current_index]; /* <-- read before the bounds check */
if (*buffer_length < 1)
{
return(NX_SECURE_X509_ASN1_LENGTH_TOO_LONG);
}
```
The remainder of the function is correctly ordered. The multi-byte length path is guarded by `length_bytes > 4 || length_bytes > *buffer_length` before its read loop, the decoded value is checked against `length > *buffer_length`, and the second single-byte length read follows its own `*buffer_length < 1` guard. The tag read is the only load placed ahead of its check.
🎖@cveNotify
The `_nx_secure_x509_asn1_tlv_block_parse()` function parses ASN.1 TLV (tag-length-value) blocks out of DER-encoded data. It is the primitive underneath all X.509 certificate parsing in NetX Secure, and therefore runs on certificates supplied by a remote peer during the TLS handshake.
The function reads the one-byte ASN.1 tag from the caller's buffer *before* checking that the buffer holds at least one byte. When a caller passes a remaining length of zero, the guard correctly returns `NX_SECURE_X509_ASN1_LENGTH_TOO_LONG`, but the read has already happened one byte past the end of the buffer.
code:
nx_secure/src/nx_secure_x509_asn1_tlv_block_parse.c
```
UINT _nx_secure_x509_asn1_tlv_block_parse(const UCHAR *buffer, ULONG *buffer_length, USHORT *tlv_type,
USHORT *tlv_tag_class, ULONG *tlv_length,
const UCHAR **tlv_data, ULONG *header_length)
{
UINT current_index;
USHORT current_tag;
ULONG length;
ULONG length_bytes;
current_index = 0;
current_tag = buffer[current_index]; /* <-- read before the bounds check */
if (*buffer_length < 1)
{
return(NX_SECURE_X509_ASN1_LENGTH_TOO_LONG);
}
```
The remainder of the function is correctly ordered. The multi-byte length path is guarded by `length_bytes > 4 || length_bytes > *buffer_length` before its read loop, the decoded value is checked against `length > *buffer_length`, and the second single-byte length read follows its own `*buffer_length < 1` guard. The tag read is the only load placed ahead of its check.
🎖@cveNotify
🚨 CVE-2026-102759
NetX Secure TLS accepts an empty application-data record without verifying its message authentication code. In `_nx_secure_verify_mac`, a decrypted application record whose length equals the negotiated MAC size is treated as valid and returns success after advancing the receive sequence number. The received MAC is never generated or compared.
Empty TLS application-data records are legal, and are commonly emitted by TLS 1.0 implementations as a BEAST mitigation.
🎖@cveNotify
NetX Secure TLS accepts an empty application-data record without verifying its message authentication code. In `_nx_secure_verify_mac`, a decrypted application record whose length equals the negotiated MAC size is treated as valid and returns success after advancing the receive sequence number. The received MAC is never generated or compared.
Empty TLS application-data records are legal, and are commonly emitted by TLS 1.0 implementations as a BEAST mitigation.
🎖@cveNotify
🚨 CVE-2026-102760
When NetX Secure is built with `NX_SECURE_KEY_CLEAR`, every TLS record sent on an active session is wiped after it has been handed to TCP. By then the TCP layer owns the packet chain and may already have released it to the packet pool. The wipe therefore writes zeros into packets that are free or in use by another thread, and when a reused packet's pointers no longer describe the old data, the length of the wipe underflows and it runs past the end of the packet pool.
🎖@cveNotify
When NetX Secure is built with `NX_SECURE_KEY_CLEAR`, every TLS record sent on an active session is wiped after it has been handed to TCP. By then the TCP layer owns the packet chain and may already have released it to the packet pool. The wipe therefore writes zeros into packets that are free or in use by another thread, and when a reused packet's pointers no longer describe the old data, the length of the wipe underflows and it runs past the end of the packet pool.
🎖@cveNotify
🚨 CVE-2026-102761
NetX Duo's WebSocket client resets the unmasking cursor to the first `NX_PACKET` each time it advances through a chained packet, while the loop's upper bound belongs to the current packet. With the standard contiguous packet-pool layout, a masked server frame split across two packets therefore drives the XOR loop through the first packet's unused payload area and on through the second packet's `NX_PACKET` control block.
The four-byte WebSocket masking key controls the bytes written, so the corruption is attacker-chosen rather than incidental.
🎖@cveNotify
NetX Duo's WebSocket client resets the unmasking cursor to the first `NX_PACKET` each time it advances through a chained packet, while the loop's upper bound belongs to the current packet. With the standard contiguous packet-pool layout, a masked server frame split across two packets therefore drives the XOR loop through the first packet's unused payload area and on through the second packet's `NX_PACKET` control block.
The four-byte WebSocket masking key controls the bytes written, so the corruption is attacker-chosen rather than incidental.
🎖@cveNotify