Lukas Johannes Moeller reported a bug in libsimaka related to the processing of certain EAP-SIM/AKA attributes that can lead to an infinite loop, a crash or even remote code execution.
Integer Underflow When Handling EAP-SIM/AKA Attributes
The libsimaka library doesn't check the length field in the header of certain EAP-SIM/AKA attributes for zero, which can cause an integer underflow that may lead to an infinite loop or a heap-based buffer overflow that's potentially exploitable for remote code execution. Affected are all strongSwan versions since 4.3.6.
CVE-2026-35330 has been assigned for this vulnerability.
Missing Check for Length Zero in libsimaka
The libsimaka library contains code shared by the implementations of EAP-SIM and EAP-AKA, which can be used for authentication during IKEv2. In particular, the parsing of attributes, of which many are shared by both protocols, is implemented in the library.
The header of such attributes consists of a single byte for the attribute type, followed by a single byte for the complete length of the attribute in 4-byte chunks, which is then followed by the attribute data. So a valid attribute should have a length of at least 1.
Some attribute types have a fixed length (including those without data, where the length field is followed by two reserved bytes), some start with an additional two-byte length field with byte- or even bit-accurate actual length of the data, and some have a variable length simply defined by the length in the header.
For the latter, the code ensured that there is still enough data in the message to extract hdr->length * 4 bytes, however, it didn't check that the length is at least 1. So when it calculated the length of the data by subtracting the 2 or 4 bytes of the header (AT_ENCR_DATA and AT_RAND have two reserved bytes after the header), this caused an integer underflow as follows:
data = chunk_create(in.ptr + 2, hdr->length * 4 - 2);
in = chunk_skip(in, hdr->length * 4);What can also be seen is that chunk_skip() is a no-op in this case and in is not modified. The latter causes an infinite loop for attributes of type AT_PADDING, which are not stored in the list of parsed attributes. For all other attributes, the library creates a copy to store in a list via the following code:
attr = malloc(sizeof(attr_t) + data.len);
attr->len = data.len;
attr->type = type;
memcpy(attr->data, data.ptr, data.len);The size of attr_t is between 8 and 16 bytes (depends on padding and the sizes of size_t and the simaka_attribute_t enum), so there will be a positive allocation between 4 and 12 bytes. However, because data.len (size_t) is huge due to the underflow, the memcpy() call in the code causes a massive buffer overflow that likely causes a crash due to a segmentation fault immediately.
Remote code execution might be possible due to this issue.
As mentioned in the introduction, credit to Lukas Johannes Moeller for finding this vulnerability. It was independently found by Ryo Shimada (University of Tsukuba / Powder Keg Technologies, Inc.) as well as @DCWebGuy. Thanks to all of them for finding it and reporting it responsibly.
Mitigation
Clients and servers that don't use EAP-SIM/AKA authentication are not vulnerable. Servers that terminate EAP-SIM/AKA on a RADIUS server are also not vulnerable.
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.