A TFTP server that answers with a short ERROR packet makes the client read up to 64 bytes past the received datagram. Each receive pat

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:

 1 
 2 
 3 
 4/* addons/tftp/nxd_tftp_client.c:1769 */
 5 
 6 
 7 
 8for (i = 0; (i < (sizeof(tftp_client_ptr -> nx_tftp_client_error_string) - 1)) && (*buffer_ptr); i++)
 9 
10 

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.

 1 
 2 
 3 
 4ERROR: AddressSanitizer: heap-buffer-overflow
 5 
 6 
 7 
 8READ of size 1 at 0x60d0000000c8 thread T4
 9 
10    #0 _nxd_tftp_client_file_read  addons/tftp/nxd_tftp_client.c:1769
11 
12 
130x60d0000000c8 is 0 bytes to the right of 136-byte region
14 
15 

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.