Haruto Kimura reported a bug in libtls related to the processing of ECDH public values in TLS < 1.3 that can lead to a crash caused by a null-pointer dereference.
NULL-Pointer Dereference When Handling ECDH Public Value in TLS
The libtls library doesn't correctly check the length of a received ECDH public value when using a TLS version before 1.3, which can cause a crash due to a NULL-pointer dereference. Affected are all strongSwan versions since 4.5.0.
CVE-2026-35332 has been assigned for this vulnerability.
Missing Length Check Before Accessing ECDH Public Values in libtls
The libtls library contains code related to the TLS protocol, which can be used for various TLS-based EAP methods during IKEv2 authentication (EAP-TLS, EAP-PEAP/TTLS).
With versions before 1.3, the public value of an (EC)DH key exchange, as used with DHE cipher suites, is transported via a client_key_exchange handshake type. The server implementation processes these in the tls_server.c::process_key_exchange_dhe() function, which handles ECDH as well as classic DH values. The client implementation in tls_peer.c::process_ec_key_exchange() only processes ECDH pubic values and is not vulnerable.
For ECDH, the public value can be transmitted in compressed or uncompressed form, which is indicated by the first byte of the value. As strongSwan only supports the uncompressed form, there is a check of that value. Unfortunately, the length check that precedes it is incorrect:
if ((ec && !reader->read_data8(reader, &pub)) ||
(!ec && (!reader->read_data16(reader, &pub) || pub.len == 0)))
{
DBG1(DBG_TLS, "received invalid Client Key Exchange");
this->alert->add(this->alert, TLS_FATAL, TLS_DECODE_ERROR);
return NEED_MORE;
}The ec flag indicates whether this is an ECDH key exchange and, as can be seen, only in the !ec case is ensured that the read public value is not empty. So empty ECDH values are accepted and can cause a null-pointer dereference when the first byte is checked.
Note that if some data follows the empty client_key_exchange, this just causes a 1-byte out-of-bounds read that has no further consequences as the TLS session is immediately terminated (ether because the read value doesn't match TLS_ANSI_UNCOMPRESSED or the ECDH implementation rejects the empty public value). Only if the TLS record ends right after the length byte of the empty attribute will the reader implementation set its internal buffer to chunk_empty that causes it to return a NULL pointer.
Remote code execution is not possible due to this issue.
As mentioned in the introduction, credit to Haruto Kimura (Stella) for finding this vulnerability and reporting it responsibly.
Mitigation
Servers that don't initiate any TLS-based EAP methods and don't allow clients to trigger their initiation using EAP-Nak (via eap-dynamic plugin) are not vulnerable.
Such EAP methods may be used if ECDH is disabled via key_exchange config, as the affected cipher suites won't be accepted. Similarly, only allowing TLS 1.3 also prevents the vulnerable code path.
Finally, providing EAP via RADIUS server also prevents the issue completely.
The just released strongSwan 6.0.6 fixes this vulnerability. For older releases, we provide a patch that fixes the vulnerability and should apply with appropriate hunk offsets.