GHSA-3p2g-x7hh-3w4c: NetX Secure DTLS server allocates a session for each new source before the cookie exchange and never reclaims it, so spoofed datagrams exhaust the session pool
In Eclipse ThreadX NetX Duo versions 6.0 through 6.5.2.202603a, the NetX Secure DTLS server allocates a session from its fixed session pool for the first datagram from any unrecognised address and port, before the cookie exchange, and never releases a session whose handshake stalls. A remote, unauthenticated attacker can exhaust the pool with one spoofed datagram per source and deny DTLS service to legitimate clients until the application resets the sessions.
Event History
Frequently Asked Questions
Which deployments are exposed to this denial of service?
Deployments using the NetX Secure DTLS server in Eclipse ThreadX NetX Duo versions 6.0 through 6.5.2.202603a are affected. The issue concerns the server's fixed DTLS session pool.
Does exploitation require authentication or a completed DTLS handshake?
No. A remote unauthenticated attacker can send a single spoofed datagram for each source address and port; the server allocates sessions before completing the cookie exchange.
What happens after the session pool is exhausted?
Legitimate clients are denied DTLS service because no session capacity remains. Stalled handshake sessions are not released until the application resets them.
What can be done if updating is not immediately possible?
The provided information identifies application session resets as the way to reclaim stalled sessions. No other mitigation or configuration workaround is specified.