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:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

/* 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:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

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.

Weakness

The product reads data past the end, or before the beginning, of the intended buffer.

Potential Mitigations

• Assume all input is malicious. Use an “accept known good” input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
• When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, “boat” may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as “red” or “blue.”
• Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code’s environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
• To reduce the likelihood of introducing an out-of-bounds read, ensure that you validate and ensure correct calculations for any length argument, buffer size calculation, or offset. Be especially careful of relying on a sentinel (i.e. special character such as NUL) in untrusted inputs.

Related Attack Patterns

• https://cwe.mitre.org/data/definitions/540.html

References

• https://github.com/eclipse-threadx/netxduo/security/advisories/GHSA-wr79-332c-ff8f