Debian Patches

Status for strongswan/6.0.1-6+deb13u7

Patch Description Author Forwarded Bugs Origin Last update
0011-libradius-Reject-undersized-attributes-in-enumerator.patch libradius: Reject undersized attributes in enumerator
attribute_enumerate() accepts RADIUS attributes whose length byte is
smaller than sizeof(rattr_t) (2). For length == 0, the iterator never
advances and traps callers — including verify() — in a non-advancing
loop. For length == 1, misaligned packed-struct reads occur.

Add a separate check for this->next->length < sizeof(rattr_t) after
the existing truncation guard. This mirrors radius_message_parse(),
which already distinguishes invalid length from truncation.		 Lukas Johannes Möller <research@johannes-moeller.dev> no 2026-03-12
0012-tls-server-Only-accept-non-empty-ECDH-public-keys-wi.patch tls-server: Only accept non-empty ECDH public keys with TLS < 1.3
This prevents a crash due to a null-pointer dereference when processing
an empty ECDH public key.

The previous length check only applied in the `!ec` case, so in the `ec`
case, the access to `pub.ptr[0]` was unguarded. If a crafted TLS
record ends with an empty ClientKeyExchange, then `read_data8` sets
`pub` to `chunk_empty`, causing a null-pointer dereference.

Note that if some data follows the empty ClientKeyExchange, this just
causes a 1-byte out-of-bounds read that has no further effect as the
TLS session is aborted immediately. Either because the read value
doesn't equal TLS_ANSI_UNCOMPRESSED or because the empty public key
is rejected by `set_public_key()`.

The referenced commit that introduced the pointer access, added the
check for `pub.len` specifically to the `!ec` case, while the pointer
access was initially unconditional (probably because the code was just
copied from `tls_peer.c` which processes ECDH public keys in a separate
function, so there was no `ec` flag). The latter was fixed a couple of
days later with 7b3c01845f63 ("Read the compression type byte for EC
groups, only"). However, that commit didn't change the length check.
Anyway, it's possible that the original intention was to add the check
to the `ec` case on the previous line, or that there was some confusion
with the parenthesis and something like the current code was intended to
begin with.		 Tobias Brunner <tobias@strongswan.org> no 2026-03-20
0013-tls-server-Prevent-infinite-loop-if-supported-versio.patch tls-server: Prevent infinite loop if supported versions are too short

If the extension doesn't contain a multiple of two bytes, the previous
code would get stuck in an infinite loop as `remaining()` continued to
return TRUE while `read_uint16()` failed to parse a value. Initiating
several connections with such an extension allows a DoS attack as no
threads would eventually be available to handle packets/events.		 Tobias Brunner <tobias@strongswan.org> no 2026-03-25
0014-pkcs5-pkcs7-Avoid-NULL-pointer-dereference-when-veri.patch pkcs5/pkcs7: Avoid NULL pointer dereference when verifying padding
Can be triggered via empty PKCS#7 encrypted- or enveloped-data content
in IKEv1 CERT payload.		 Tobias Brunner <tobias@strongswan.org> no 2026-03-25
0015-constraints-Case-insensitive-matching-and-reject-exc.patch constraints: Case-insensitive matching and reject excluded DN name constraints

The case is generally ignored when matching identities. So this is
an issue with excluded name constraints where a malicious intermediate
CA could evade the constraints by issuing certificates with names that
just modify the case (e.g. strongSwan.org instead strongswan.org).

Note that it's likely that permitted name constraints are preferred over
excluded name constraints as it might be difficult to come up with a
conclusive list of names to exclude.

With directoryName (DN) name constraints the issue is a bit more comples.
Some RDNs have to be matched in a case-insensitive manner, which we e.g.
do in `identification.c::rdn_equals`. By not doing it for name
constraints, a malicious intermediate CA could evade an excluded name
constraint just by modifying the case in such an RDN.

While we could use the mentioned function in `dn_matches`, this doesn't
properly fix the problem because the function is basically too strict.
Especially in regards to RDNs of type UTF8String, which are only compared
binary. To match these properly, we'd have to implement the string
preparation described in RFC 5280, section 7.1 and the referenced RFCs.
Until that's the case, we reject excluded name constraints of type
directoryName as we are unable to enforce them.		 Tobias Brunner <tobias@strongswan.org> no 2026-03-23
0027-eap-ttls-peap-Return-auth-cfg-with-details-on-TLS-an.patch eap-ttls/peap: Return auth-cfg with details on TLS and inner EAP method

This fixes several issues with binding identities to the IKE SA.

If the client is authenticated with a certificate, the previous code still
used the client's proclaimed inner EAP-Identity when starting the EAP-TNC
method. So that method would potentially operate on an unverified
identity.

Second, if the inner EAP method overrides the client identity (the only
one is currently EAP-MSCHAPV2), the missing merge meant that the outer
IKE/EAP identity could potentially be unconfirmed.

For inner methods that don't override the identity (e.g. EAP-MD5), not
propagating the inner EAP-Identity could potentially have the same
effect.

While the EAP-TTLS implementation returned the auth-cfg of the TLS
exchange since the first referenced commit, this was mainly intended to
enforce public key constraints. So it didn't cover the phase 2 EAP
methods. For some reason EAP-PEAP did not get that method at all in that
changeset, so we'll add that now.

Additionally, the EAP-PEAP implementation now forwards the phase 2 EAP
method type to EAP-TNC like the EAP-TTLS implementation already did,
which allows a more informed decision on the client's identity.		 Tobias Brunner <tobias@strongswan.org> no 2026-07-27
0028-ikev2-Properly-reject-CREATE_CHILD_SA-requests-on-un.patch ikev2: Properly reject CREATE_CHILD_SA requests on unestablished IKE_SAs

The previous check was not actually enforced as long as there were still
tasks in the passive queue (it was originally added to fix an issue on
initiators, so the passive queue was expected to be empty). This allowed
an unauthenticated attacker to potentially establish a usable Child SA
if certain preconditions were met.

First, it required that the initiator is authenticated with EAP so the
authentication and the creation of the first Child SA is deferred.
Second, the responder must either not configure an IP address pool or
an explicit remote TS, otherwise, traffic selector negotiation fails.

Note that the half-open IKE SA and the installed IPsec SA will be removed
after the default timeout of 30 seconds.		 Tobias Brunner <tobias@strongswan.org> no 2026-07-27
02_disable-bypass-lan.patch Don't load bypass-lan plugin by default Yves-Alexis Perez <corsac@debian.org> no 2019-01-02
03_systemd-service.patch Tune the ipsec systemd service file
- add a reload argument
- don't wait on syslog		 Romain Francoise <rfrancoise@debian.org> no 2019-01-02
04_disable-libtls-tests.patch Disable libtls tests
They're too intensive for the buildd network and cause FTBFS		 Romain Francoise <rfrancoise@debian.org> no 2019-01-02
dont-load-kernel-libipsec-plugin-by-default.patch dont-load-kernel-libipsec-plugin-by-default Christian Ehrhardt <christian.ehrhardt@canonical.com> no 2020-11-11
0001-openssl-Fix-testing-KDF_PRF-in-the-constructor-with-.patch openssl: Fix testing KDF_PRF in the constructor with OpenSSL 3.5.1

Setting the salt to NULL now fails, so we set it to hash length's zeroes,
which is the default value for HKDF-Extract if no salt is passed.

Fixes strongswan/strongswan#2828		 Tobias Brunner <tobias@strongswan.org> no 2025-07-10
0002-openssl-Don-t-allocate-salt-if-PRF-hash-is-unknown.patch openssl: Don't allocate salt if PRF/hash is unknown
This can happen if e.g. AES-XCBC is selected.		 Tobias Brunner <tobias@strongswan.org> no 2025-07-11
0007-eap-mschapv2-Fix-length-check-for-Failure-Request-pa.patch eap-mschapv2: Fix length check for Failure Request packets on the client

For message lengths between 6 and 8, subtracting HEADER_LEN (9) causes
`message_len` to become negative, which is then used in calls to malloc()
and memcpy() that both take size_t arguments, causing an integer
underflow.

For 6 and 7, the huge size requested from malloc() will fail (it exceeds
PTRDIFF_MAX) and the returned NULL pointer will cause a segmentation
fault in memcpy().

However, for 8, the allocation is 0, which succeeds. But then the -1
passed to memcpy() causes a heap-based buffer overflow (and possibly a
segmentation fault when attempting to read/write that much data).
Fortunately, if compiled with -D_FORTIFY_SOURCE=3 (the default on e.g.
Ubuntu), the compiler will use __memcpy_chk(), which prevents that buffer
overflow and causes the daemon to get aborted immediately instead.		 Tobias Brunner <tobias@strongswan.org> no 2025-10-09
0008-nm-Create-safe-copies-of-files-for-user-specific-con.patch nm: Create safe copies of files for user-specific connections
This ensures that only certificates/private keys accessible by the
configured user are accessed and prevents attackers from misusing
other user's credentials.

Also removed setting NM_VERSION_MIN_REQUIRED, which suppresses deprecation
warnings that were added with newer API versions, and
NM_VERSION_MAX_ALLOWED, which warns if using functions added in newer
API versions, so we always build against the latest API available.

But we check explicitly for the required function so this works with
older NM versions and automatically will use it if the function is
backported.

Note that we can't use BUILD_FROM_FILE to read the temporary files as that
uses mmap() which SELinux policies prevent us from using at the location
these files are stored ([/var]/run/NetworkManager/cert/).


Includes other backported fixes.		 Tobias Brunner <tobias@strongswan.org> no 2025-11-26
0009-eap-ttls-Prevent-crash-if-AVP-length-header-field-is.patch eap-ttls: Prevent crash if AVP length header field is invalid
The length field in the AVP header includes the 8 bytes of the header
itself. Not checking for that and later subtracting it causes an
integer underflow that usually triggers a crash when accessing a
NULL pointer that resulted from the failing chunk_alloc() call because
of the high value.

The attempted allocations for invalid lengths (0-7) are 0xfffffff8,
0xfffffffc, or 0x100000000 (0 on 32-bit hosts), so this doesn't result
in a buffer overflow even if the allocation succeeds.		 Tobias Brunner <tobias@strongswan.org> no 2026-03-05
0010-libsimaka-Reject-zero-length-EAP-SIM-AKA-attributes.patch libsimaka: Reject zero-length EAP-SIM/AKA attributes
parse_attributes() accepts hdr->length == 0 in the AT_ENCR_DATA,
AT_RAND, AT_PADDING, default branches. The code then subtracts the
fixed attribute header size from the encoded length, which underflows
and exposes a wrapped payload length to later code. In particular,
for the cases where add_attribute() is called, this causes a heap-based
buffer overflow (a buffer of 12 bytes is allocated to which the wrapped
length is written). For AT_PADDING, the underflow is irrelevant as
add_attribute() is not called. Instead, this results in an infinite loop.

Reject zero-length attributes before subtracting the attribute header.		 Lukas Johannes Möller <research@johannes-moeller.dev> no 2026-03-11
0016-gmp-Avoid-crash-and-timing-leaks-in-PKCS-1-v1.5-decr.patch gmp: Avoid crash and timing leaks in PKCS#1 v1.5 decryption padding validation

This fixes a potential crash due to a null-pointer dereference if rsadp()
returns NULL (e.g. with an all-zero ciphertext).

And it also implements the PKCS#1 v1.5 decryption padding check in
constant time.

The timing leak caused by the previous implementation was measured at
~17.5 μs at 3 GHz, which could allow a Bleichenbacher-like attack in
LAN environments. However, because of how RSA encryption is used in
strongSwan, this is not that much of an issue in practice. The mechanism
is only used for two use cases. One is SCEP/EST via PKCS#7 enveloped
data. Fortunately, this can not be triggered in significant numbers by
an attacker. The other use case is TLS as used by EAP methods (EAP-TLS,
EAP-PEAP/TTLS) during the authentication. While the cipher suites that
use RSA encryption are still enabled by default, the TLS messages are
wrapped in EAP and encrypted by IKE, making any kind of attack difficult.

Note that the gmp plugin isn't enabled anymore by default. And even
before that, most setups had the openssl plugin enabled, which has
priority over the gmp plugin. So it's unlikely the plugin was used in
practice.

Also note that this patch doesn't modify libstrongswan's Makefile.am
to avoid potentially requiring autotools when patching a tarball.		 Tobias Brunner <tobias@strongswan.org> no 2026-03-24
0017-identification-Fix-double-free-when-cloning-empty-ID.patch identification: Fix double-free when cloning empty IDs
The clone() method was missing a branch when there is an encoded chunk
of length 0 that still needed to be cloned. Otherwise, the destruction
of the clone frees the same pointer that the original owns.

This double free was found with an improved `fuzz_ids` fuzz harness and
a two byte input to create an identification from "@#" or [0x40, 0x23].
It can also be triggered with `<type>:#` e.g. `dns:#`.

One of the problematic constructors is used to parse EAP-Identities,
which are cloned before storing them in the auth-cfg. So this can be
triggered by an unauthenticated attacker.

Note that while the length check was already added with 418dbd624363
("cloning %any ID without zero-byte memleak") and identities that trigger
this can be created since 86ab5636c2c9 ("support for @#hex ID_KEY_ID
identification_t"), it was the referenced commit that made the length
check problematic.		 "R. Elliott Childre" <elliottchildre329@gmail.com> no 2026-05-18
0018-openssl-Fix-undefined-memory-access-when-verifying-P.patch openssl: Fix undefined memory access when verifying PKCS#7 containers

If the signerInfo or recipientInfo structure doesn't contain
issuerAndSerialNumber but instead a subjectKeyIdentifier, then the called
functions will leave the passed name and serial numbers unchanged. While
openssl_x509_name2id() prevents a NULL-pointer dereference, it tries to
DER-encode the object at the passed pointer via i2d_X509_NAME().
Depending on the stack contents, this likely causes a segmentation fault.		 Tobias Brunner <tobias@strongswan.org> no 2026-06-01
0019-openssl-Fix-memory-leaks-after-enumerating-certifica.patch openssl: Fix memory leaks after enumerating certificates in PKCS#7 container

This can be triggered via IKEv1.		 Tobias Brunner <tobias@strongswan.org> no 2026-06-15
0020-eap-aka-Only-accept-AKA-Synchronization-Failure-if-e.patch eap-aka: Only accept AKA-Synchronization-Failure if expected
This fixes a NULL-pointer dereference if the client sends such an error
before the server issued a challenge and allocated this->rand.		 Tobias Brunner <tobias@strongswan.org> no 2026-06-04
0021-message-Avoid-memory-leak-if-string-buffer-for-messa.patch message: Avoid memory leak if string buffer for message is too small
This leaked 40 or 80 bytes per parsed message for the enumerators that
were not destroyed. While triggering an OOM condition will require quite
a lot of messages and the DoS protection also helps avoiding that this
is triggered quickly, it all depends on the memory constraints of the
system and the time available to the attacker. Also, if IKEv1 is allowed,
it could get quicker as the lack of message IDs doesn't allow dismissing
unexpected messages before parsing them.		 Tobias Brunner <tobias@strongswan.org> no 2026-06-08
0022-pkcs5-Validate-parsed-parameters-to-avoid-DoS-attack.patch pkcs5: Validate parsed parameters to avoid DoS attacks
With the unbounded iterations, an attacker can craft a PKCS#7 file and
send it during IKEv1 to block the processing thread practically for an
unlimited amount of time.

As the key length is used for an allocation on the stack, not limiting
it could cause a crash. We validate it after parsing the params, but
since `encryption_algorithm_from_oid()` only returns trusted key lengths
that are lower than the limit, that's fine.

The unlimited salt length had no direct impact (the maximum is bound by
the accepted message size), but we now limit it as well before cloning.		 Tobias Brunner <tobias@strongswan.org> no 2026-06-23
0023-x509-Avoid-NULL-pointer-dereference-if-issuerName-is.patch x509: Avoid NULL-pointer dereference if issuerName is missing in attribute certificate

If neither authoritiyKeyIdentifier nor issuerName are encoded in an
attribute certificate, the validation in `acert_validator.c:verify()`
will cause a NULL-pointer dereference via `issued_by()` (the lookup
with NULL identity will enumerate all trusted certificates).		 Tobias Brunner <tobias@strongswan.org> no 2026-06-19
0024-x509-Fix-memory-leaks-when-parsing-attribute-certifi.patch x509: Fix memory leaks when parsing attribute certificates
This can be triggered by an attribute certificate with lots of GeneralName
entries or AuthorityKeyIdentifier extensions. There is no verification
before the certificate is parsed.		 Tobias Brunner <tobias@strongswan.org> no 2026-06-12
0025-x509-Prevent-infinite-loop-when-parsing-ietfAttrSynt.patch x509: Prevent infinite loop when parsing ietfAttrSyntax in attribute certificates

This is the same issue that was fixed with 407fcca200fd ("asn1-parser:
Fix CHOICE parsing") for other CHOICE elements. This one was missed and
can be triggered pre-auth by sending an attribute certificate to a peer.
Since it's parsed before verifying it, the certificate doesn't have to
be valid.

For versions older than 5.5.3, this patch requires prior application of
the fix for CVE-2017-9023, which introduced proper CHOICE handling in
the ASN.1 parser.		 Tobias Brunner <tobias@strongswan.org> no 2026-07-01
0026-ikev2-Prevent-use-after-free-during-collision-after-.patch ikev2: Prevent use-after-free during collision after passive multi-KE rekeying failed

During a multi-KE rekey collision, where the initial response to the
active rekeying is delayed (or withheld), the active task already keeps
track of the passive task to eventually resolve the collision (it can
only do so once all nonces are known).

If the passive task then fails, e.g. due to a missing or invalid KE
payload, and completes with SUCCESS, `collide()` previously recognized
that the passive task is not yet complete returned FALSE, which caused
the task manager to destroy the task. However, the reference in the
active task would remain. So once the active rekeying progresses and
the collision is resolved, that dangling pointer would get dereferenced
for an indirect method call. This happens via the `get_lower_nonce`
function pointer of the `child_create_t` instance in the private task
struct. So besides having to be authenticated, an attacker has to get
two indirections right to exploit this flaw for a potential RCE.
Otherwise, the effects are a crash or basically undefined behavior
triggered by the method call.

By passing whether the passive task is done (and would get destroyed),
the active tasks can properly clear the held reference.

Note that this patch includes another fix for a state change during
Child SA rekeying that's included in 6.1.0 (4611f41b1e14 ("child-rekey:
Only reset state of SAs not actively rekeyed if passive rekeying
fails")).		 Tobias Brunner <tobias@strongswan.org> no 2026-06-05

All known versions for source package 'strongswan'

Links