Debian Patches

Status for strongswan/5.9.8-5+deb12u4

Patch Description Author Forwarded Bugs Origin Last update
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
0005-libtls-Fix-authentication-bypass-and-expired-pointer.patch libtls: Fix authentication bypass and expired pointer dereference
`public` is returned, but previously only if a trusted key was found.
We obviously don't want to return untrusted keys. However, since the
reference is released after determining the key type, the returned
object also doesn't have the correct refcount.

So when the returned reference is released after verifying the TLS
signature, the public key object is actually destroyed. The certificate
object then points to an expired pointer, which is dereferenced once it
itself is destroyed after the authentication is complete. Depending on
whether the pointer is valid (i.e. points to memory allocated to the
process) and what was allocated there after the public key was freed,
this could result in a segmentation fault or even code execution.		 Tobias Brunner <tobias@strongswan.org> no 2023-02-17
0006-charon-tkm-Validate-DH-public-key-to-fix-potential-b.patch charon-tkm: Validate DH public key to fix potential buffer overflow
Seems this was forgotten in the referenced commit and actually could lead
to a buffer overflow. Since charon-tkm is untrusted this isn't that
much of an issue but could at least be easily exploited for a DoS attack
as DH public values are set when handling IKE_SA_INIT requests.		 Tobias Brunner <tobias@strongswan.org> no 2023-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-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
0009-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
0010-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
0011-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
0012-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
0013-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
0014-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
0015-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

All known versions for source package 'strongswan'

Links