CVE-2026-102713 Eclipse ThreadX NetX TFTP 服务端堆缓冲区溢出漏洞
影响未认证攻击者可触发堆缓冲区越界读取，导致信息泄露或服务崩溃
Eclipse ThreadX 的 NetX TFTP 服务端组件在处理 DATA 报文时缺少长度上限校验，仅拒绝小于 4 字节的报文，未按协议最大值 4 + NX_TFTP_FILE_TRANSFER_MAX 做上界检查。由于 TFTP 协议本身无认证机制，该缺陷可在认证前被远程触发。
影响范围
Eclipse ThreadX NetX 的 TFTP 服务端插件（addons/tftp/nxd_tftp_server.c），具体受影响版本范围暂无公开信息。
漏洞详情
漏洞类型为堆缓冲区越界读取（CWE-125）。成因是代码将 nx_packet_length - 4 直接传给 FileX 的 fx_file_write，而 nx_packet_length 表示整个数据包链的总长度而非单个连续缓冲区长度，导致 FileX 在拷贝时越过首个数据包末尾读取。攻击者只需向 TFTP 服务端口发送一个超长 DATA 报文即可触发，AddressSanitizer 已复现 heap-buffer-overflow。
利用条件与风险
利用前提是目标设备开放 TFTP 服务且攻击者网络可达，无需任何认证。实战中可造成敏感内存信息泄露或服务崩溃，若越界数据被写入文件还可能引发进一步风险。
修复建议
官方修复方案暂无公开信息，建议关注 Eclipse ThreadX 官方安全公告并升级至修复版本；临时缓解措施包括在报文处理前增加对 nx_packet_length 的上限校验、限制 TFTP 服务网络暴露面或临时禁用该服务。
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.