Kazuma Matsumoto reported a bug in the eap-ttls plugin related to handling EAP-TTLS AVPs that can lead to resource exhaustion or a crash.
Integer Underflow When Handling EAP-TTLS AVP
The eap-ttls plugin doesn't check the length field in the header of attribute-value pairs (AVPs) tunneled in EAP-TTLS, which can cause an integer underflow that may lead to resource exhaustion or a crash. An unauthenticated attacker could exploit this for a DoS attack by sending a crafted message. Affected are all strongSwan versions since 4.5.0.
CVE-2026-25075 has been assigned for this vulnerability.
Missing Length Field Check for AVPs in eap-ttls Plugin
The eap-ttls plugin implements the EAP-TTLSv0 protocol that can be used to tunnel other Extensible Authentication Protocol (EAP) methods (e.g. EAP-MSCHAPv2) under the protection of a TLS session. It's defined in RFC 5281 and can be used within the EAP framework during IKEv2.
The data tunneled in EAP-TTLS are transported within attribute-value pairs (AVPs) that are encrypted by TLS. The header of such an AVP starts with a 4-byte code denoting the type of attribute (as defined by RADIUS/Diameter), which is generally just another EAP message (i.e. it's set to 79). That's followed by 8 bits of flags and a 3-byte length field.
This length field indicates the length of the complete AVP, so it includes the 8-byte AVP header. Without checking that the value is at least 8, the code in the plugin does this:
this->data_len = avp_len - 8;
this->input = chunk_alloc(this->data_len + (4 - avp_len) % 4);Where avp_len is an uint32_t that contains the parsed length from the header and data_len is a size_t that's intended to store the length of the AVP payload. So subtracting 8 from the parsed value causes a 32-bit integer underflow if the header encodes a length value between 0 and 7. The resulting length is rounded up to a multiple of 4, so one of the following lengths will be passed to the chunk_alloc() macro:
| len | 64-bit | 32-bit |
|---|---|---|
| 0 | 0xfffffff8 |
0xfffffff8 |
| 1 | 0xfffffffc |
0xfffffffc |
| 2 | 0xfffffffc |
0xfffffffc |
| 3 | 0xfffffffc |
0xfffffffc |
| 4 | 0xfffffffc |
0xfffffffc |
| 5 | 0x100000000 |
0x0 |
| 6 | 0x100000000 |
0x0 |
| 7 | 0x100000000 |
0x0 |
If the allocation succeeds, a lot of memory is wasted, possibly resulting in resource exhaustion, but there is more than enough room to store the data that follows the AVP header. A length of 0 is also OK as nothing is written to an empty buffer. That is, this doesn't result in a buffer overflow.
However, allocating a huge amount of memory (~4 GiB) may fail and neither chunk_alloc() nor the calling code does check for it (we generally don't do that), while the length in the chunk_t structure is still set. This will then result in a null-pointer dereference and segmentation fault when the code attempts to write to the chunk.
Remote code execution is not possible due to this issue.
As mentioned in the introduction, credit to Kazuma Matsumoto, a security researcher at GMO Cybersecurity by IERAE, Inc., for finding this vulnerability and reporting it responsibly.
Mitigation
Clients and servers that don't use EAP-TTLS authentication are not vulnerable. Servers that terminate EAP-TTLS on a RADIUS server are also not vulnerable.
The just released strongSwan 6.0.5 fixes this vulnerability. For older releases, we provide a patch that fixes the vulnerability and should apply with appropriate hunk offsets.