CVE-2026-35330: Pre-Auth Heap Overflow in strongSwan libsimaka (EAP-SIM/AKA)

Overview

CVE	CVE-2026-35330
Advisory	strongSwan Security Advisory
Component	src/libsimaka/simaka_message.c (parse_attributes())
Affected	strongSwan <= 6.0.5 when EAP-SIM or EAP-AKA is enabled
Fixed	strongSwan 6.0.6
Class	CWE-191 (Integer Underflow), CWE-122 (Heap Buffer Overflow)
SUSE	SUSE CVE Entry
CVSS v4.0	9.2 (Critical, SUSE) -- CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
Found and patched by	Lukas Johannes Moeller (@JohannesLks)

TL;DR

The EAP-SIM/AKA parser accepts an attribute with length == 0. That value passes the existing bounds check, underflows the payload-length calculation to nearly SIZE_MAX, and reaches a heap copy into a tiny allocation. In the reproduced path, one unauthenticated IKE_AUTH packet crashes charon before user authentication completes.

Root Cause

The parser checks whether the advertised attribute length exceeds the remaining input, but it does not reject zero:

if (hdr->length * 4 > in.len || in.len < 4)
    return invalid_length(hdr->type);

data = chunk_create(in.ptr + 4, hdr->length * 4 - 4);

For hdr->length == 0, the comparison becomes 0 > in.len and passes. The subtraction then wraps from 0 - 4 to 0xfffffffffffffffc on a 64-bit build.

attr = malloc(sizeof(attr_t) + data.len);
// 16 + 0xfffffffffffffffc wraps to 12
memcpy(attr->data, data.ptr, data.len);
// huge copy into a 12-byte allocation

The sibling branches for attributes such as AT_RES, AT_IDENTITY, and AT_VERSION_LIST already had a hdr->length < 1 guard. The vulnerable branches simply missed the same invariant.

Reachability

The vulnerable parser is reachable pre-authentication through IKEv2 EAP handling:

IKE_SA_INIT
  -> IKE_AUTH with EAP-SIM or EAP-AKA
    -> simaka_message_create_from_payload()
      -> parse_attributes()
        -> add_attribute()

The attacker must reach a strongSwan gateway configured for EAP-SIM or EAP-AKA. No VPN user credentials are required to hit the parser because the crafted EAP payload is processed while authentication is still in progress.

Exploitability

• Observed primitive: deterministic process crash in charon.
• Execution control was not demonstrated. The only useful underflow value in testing was length == 0, and the process terminates during the copy before a controlled post-overflow state becomes practical.
• Fortified builds with -D_FORTIFY_SOURCE=3 abort earlier in __memcpy_chk; that still leaves a remote crash, not a bypass.
• A related parser behavior with AT_ENCR_DATA and zero length can also create non-advancing iteration, which is availability impact rather than code execution.

Proof of Concept

A standalone proof of concept is published on Exploit-DB as EDB-ID 52587 and mirrored at github.com/JohannesLks/CVE-2026-35330. It crafts an EAP-SIM/AKA attribute with a zero length word so that hdr->length * 4 - 4 wraps near SIZE_MAX, then drives the oversized memcpy() into a small heap allocation. Built with AddressSanitizer, it shows the out-of-bounds write reachable in charon before EAP authentication completes.

Fix

strongSwan 6.0.6 adds the missing zero-length guard before computing the derived data length:

- if (hdr->length * 4 > in.len || in.len < 4)
+ if (hdr->length == 0 || hdr->length * 4 > in.len || in.len < 4)

The invariant is simple: attribute length fields must be validated for minimum size before any multiplication, subtraction, pointer advance, or copy length is derived from them.

Credits

strongSwan credits Lukas Johannes Moeller, Ryo Shimada (University of Tsukuba / Powder Keg Technologies), and @DCWebGuy for independent discovery.