Ryo Shimada reported a bug in the gmp plugin related to RSA decryption that can lead to a crash.
Possible NULL-Pointer Dereference in RSA Decryption
The gmp plugin doesn't check whether the RSA decryption yielded a valid result before checking and removing the PKCS#1 v1.5 padding, which can lead to a crash caused by a NULL-pointer dereference. Affected are all strongSwan versions since 4.3.2.
CVE-2026-35334 has been assigned for this vulnerability.
Missing Check for Valid Decryption in gmp Plugin
The gmp plugin contains a legacy implementation of the RSA public-key cryptosystem using libgmp. While mostly used for signatures, it also implements PKCS#1 v1.5 RSA encryption (see RFC 8017, section 7.2) as used by certain TLS cipher suites and SCEP/EST with PKCS#7.
After the actual decryption (the RSADP operation), the result is converted to a byte array (I2OSP operation) using the mpz_export() function. From this result, the PKCS#1 v1.5 has to be removed and verified. Unfortunately, the code doesn't check that the export actually yielded a valid result, it just goes on dereferencing the returned pointer:
stripped = em = rsadp(this, crypto);
/* PKCS#1 v1.5 8.1 encryption-block formatting (EB = 00 || 02 || PS || 00 || D) */
/* check for hex pattern 00 02 in decrypted message */
if ((*stripped.ptr++ != 0x00) || (*(stripped.ptr++) != 0x02))
{
DBG1(DBG_LIB, "incorrect padding - probably wrong rsa key");
goto end;
}
stripped.len -= 2;
/* the plaintext data starts after first 0x00 byte */
while (stripped.len-- > 0 && *stripped.ptr++ != 0x00)
if (stripped.len == 0)
{
DBG1(DBG_LIB, "no plaintext data");
goto end;
}
*plain = chunk_clone(stripped);The pointer is NULL if the result of the RSADP operation is 0 (e.g. if the ciphertext was all-zero or a multiple of n). This results in a NULL-pointer dereference and a crash.
What can also be seen in the code snippet above, is that the padding check/removal is not implemented in constant time. The different ways in which the padding can be valid/invalid (also see RFC 8017, section 7.2.2) can be distinguished to some degree, which creates a padding oracle that could potentially be used for a Bleichenbacher-style attack. Because of how RSA encryption is used in strongSwan, it's fortunately not that much of an issue. PKCS#7 decryption can't be triggered by a remote attacker and TLS-based EAP methods are additionally segmented in EAP payloads and encrypted by IKE and also only create short-lived TLS sessions
Remote code execution is not possible due to this issue.
As mentioned in the introduction, credit to Ryo Shimada (University of Tsukuba / Powder Keg Technologies, Inc.) for finding this vulnerability and reporting it responsibly.
Mitigation
Setups where the gmp plugin is not loaded are not vulnerable. If other plugins that implement RSA are loaded (e.g. openssl), the gmp plugin won't get used by default as the other plugins are preferred. When using TLS-based EAP methods and the server doesn't use an RSA key, there is also no issue. With an RSA key, it's possible to disable the TLS cipher suites that are based on a key exchange that uses RSA encryption (remove rsa from the key_exchange option or only allow TLS 1.3).
The just released strongSwan 6.0.6 fixes this vulnerability. For older releases, we provide patches that fix the vulnerability (and implement the padding check in constant-time) and should apply with appropriate hunk offsets.