R. Elliott Childre reported a bug in libcharon related to the logging of IKE messages that can lead to a denial of service via memory exhaustion.
Memory Leak During Message Stringification
When libcharon produces a string representation of an IKE message it doesn't properly release allocated enumerators when it runs out of buffer space, which can cause a small memory leak. Affected are all strongSwan versions since 4.1.2.
CVE-2026-78127 has been assigned for this vulnerability.
Enumerators Not Destroyed on Early Return in libcharon
In order to log details about a received IKE message, the message_t::parse_body() method calls get_string() to produce a string representation of the contained payloads in a fixed-size buffer. The function iterates over payloads in the message using an enumerator obtained via create_payload_enumerator().
When formatting the payload type via snprintf(), the function checks if the buffer is exhausted and if so, returns the buffer immediately. However, the code does not destroy the enumerator before these early returns. A secondary enumerator for configuration payload attributes is similarly leaked if the buffer is exhausted during configuration payload stringification. So this leaks up to 80 bytes per parsed message (before 4.4.1 only 40 bytes were leaked at most, because no details on configuration payloads were logged).
An attacker can send a large number of specially crafted IKE messages whose string representation exceeds the fixed-size stack buffer (e.g. with lots of unknown payloads or configuration attributes). Each such message causes the enumerator(s) to be leaked. Over time, the accumulated leaks can exhaust available memory, causing a denial of service.
The DoS protection mechanisms built into strongSwan slow down the accumulation but do not prevent it entirely, particularly on systems with tight memory constraints.
Remote code execution is not possible due to this issue.
As mentioned in the introduction, credit to R. Elliott Childre for finding this vulnerability and reporting it responsibly.
Mitigation
The only builds not vulnerable are those that disable debugging on levels 1 and higher during compilation (-DDEBUG_LEVEL=0).
The just released strongSwan 6.1.0 fixes this vulnerability. For older releases, we provide patches that fix the vulnerabilities and should apply with appropriate hunk offsets.