Haruto Kimura reported a bug in libtls related to the processing of the supported_versions extension in TLS that can lead to an infinite loop.
Infinite Loop When Handling Supported Versions TLS Extension
The libtls library doesn't correctly process supported_versions extensions that have a length that's not a multiple of two, which can cause an infinite loop. Affected are all strongSwan versions since 5.9.2.
CVE-2026-35328 has been assigned for this vulnerability.
Incorrect Loop Condition When Processing Supported Versions 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 TLS 1.3, the supported_versions extension was introduced to negotiate newer versions while still keeping the version field (now renamed to legacy_version) in the ClientHello, HelloRetryRequest and ServerHello messages at 0x0303 (indicating TLS 1.2) for compatibility with legacy implementations. While introduced with TLS 1.3, the extension is also parsed if TLS 1.3 is disabled (the default).
In the ClientHello message, the extension contains a list of TLS versions the client supports as two-byte values (e.g. 0x0304 for TLS 1.3). It's processed in tls_server.c::process_client_hello() as follows:
while (client_versions->remaining(client_versions))
{
if (client_versions->read_uint16(client_versions, &version))
{
if (this->tls->set_version(this->tls, version, version))
{
this->client_version = version;
break;
}
}
}So if the extension has a length that's not a multiple of two bytes (16-bits), read_uint16() will fail, while remaining() continues to succeed and leave the processing thread stuck in the outer loop. This can be exploited by an attacker to exhaust the deamon's thread pool for a DoS attack.
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.
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.