GHSA-8w5x-ff58-2fr2: Use After Free in the NetX Secure TLS Record Send Path with NX_SECURE_KEY_CLEAR

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.

_nx_secure_tls_send_record() encrypts a record in place, passes the chain to nx_tcp_socket_send(), and then, under NX_SECURE_KEY_CLEAR, walks the same chain and clears each packet from nx_packet_prepend_ptr to nx_packet_append_ptr.

On success nx_tcp_socket_send() takes ownership of the chain. When the chain has to be re-segmented, which happens when the record is larger than the MSS, when its start is not four-byte aligned, or when a chained record fits in a single packet, _nx_tcp_socket_send_internal() sends the leading segments from copies. It then either copies the rest too and releases the original chain before it returns, or trims the chain down to the last segment and queues it. A queued chain, like one that needed no re-segmenting, is released by the IP thread when the peer acknowledges it, which can happen before the wipe reaches it. Even while it is queued, the wipe zeroes data TCP still holds for retransmission. _nx_packet_release() leaves a free packet’s nx_packet_next, nx_packet_prepend_ptr and nx_packet_append_ptr untouched, so the walk follows stale pointers into the pool.

If another thread allocates one of those packets before the walk reaches it, the walk clears that thread’s data, and where nx_packet_append_ptr is below nx_packet_prepend_ptr the unsigned length underflows to nearly 4 GB. The reporter observed exactly this on an STM32H753 serving TLS 1.2 and TLS 1.3: a bus fault inside memset with a length of 0xFFFFFFFC, writing past the end of the packet pool, on the first response large enough to span several packets.

An attacker who can make the device send a TLS record spanning several packets, which for a server usually means requesting a large enough resource, can crash it. The write corrupts packets owned by other threads and memory beyond the packet pool. The written value is always zero and the attacker controls neither its target nor its length, so the realistic outcome is a denial of service rather than code execution.

Builds that define NX_SECURE_KEY_CLEAR, which is off by default, for both TLS clients and servers. DTLS is not affected: _nx_secure_dtls_send_record() does not clear the record after sending.

All NetX Duo releases from 6.0 up to and including 6.5.1.202602. The wipe after the send has been present since the first public release of NetX Secure.

CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:H, 6.5 (Medium).

Attack complexity is High because corruption requires a freed packet to be reallocated by another thread in the window between the send and the wipe, which the attacker cannot control. Integrity is Low because the corrupted memory is overwritten with zeros only.

Fixed in NetX Duo 6.5.2.202603. _nx_secure_tls_send_record() clears the chain only when nx_tcp_socket_send() fails, the one case in which the caller still owns it. On success the chain holds only ciphertext, because encryption is in place and the block buffer used for blocks that straddle two packets is already cleared under NX_SECURE_KEY_CLEAR, so nothing is lost by no longer wiping it. The receive path still clears decrypted plaintext.

The reporter’s HTTPS and MQTT regression campaign on hardware with NX_SECURE_KEY_CLEAR, TLS 1.2 and 1.3 over IPv4 and IPv6, faults without the fix and runs to completion with it. A new regression test sends a record spanning several packets and more than one MSS, and checks that the chain TCP took over is not cleared after the send; it fails without the fix in a build with NX_SECURE_KEY_CLEAR.

Building without NX_SECURE_KEY_CLEAR removes the defect, at the cost of the key and plaintext clearing that option provides elsewhere.

Reported and fixed by Edouard Malot (@EdouardMALOT) in eclipse-threadx/netxduo#442. The regression test, the review of the fix and the analysis in this advisory were produced with AI assistance under human review, in accordance with the Eclipse Foundation’s Generative AI Usage Guidelines.