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: "nx_packet_length" is the length of a chain, not of one contiguous buffer, so FileX copies past the end of the first packet: 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.