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.
Signed-off-by: Lukas Johannes Möller <research@johannes-moeller.dev>
Fixes: f8330d0395 ("Added a libsimaka library with shared message handling code for EAP-SIM/AKA")
Fixes: CVE-2026-35330
These are quite a bit faster than on AppVeyor (with ccache about a fifth,
without less than half - and they run concurrently).
We only keep the AppVeyor builds for now to test against those old
OpenSSL versions (1.1.1 and 1.0.2) for which there is still extended
support available. Even simplified like that they still take longer
than the builds on GA.
This reduces the cache storage for active branches and since caches for
different branches are separate and we abort previous builds of the same
branch, this is not necessary to ensure caches can successfully be stored.
We are still too close to the limit of 1 hour (at least with the 2019
image and the 2022 image is about the same), so reduce the build time by
not building libimcv natively, which saves about 10 minutes.
Also, only build against OpenSSL 1.0.2 (on the 2017 image) and 1.1.1 (on
the 2019 image) as these are the only versions for which OpenSSL provides
extended support.
wolfSSL 5.9.1 starts to enforce a minimum (and maximum) length for the
hash when signing. Since we'll always require SHA-1, use 20 bytes as
input in the tests to succeed with SIGN_ECDSA_WITH_NULL.
All the plugins are linked statically into the binaries, so there
is no reason to set the directories that are only required when loading
them from files.
The pa_tnc fuzzer does not rely on any plugins and the pb_tnc fuzzer is
a bit special in that it does use code from the tnccs-20 plugin, but that
doesn't actually have to be loaded as such. The fuzzer directly calls
statically linked code from the plugin.
The `cipher_suites` field has a 16-bit length field, so up to 32k 2-byte
cipher suites could technically be proposed. With `tls_cipher_suite_t`
typically being 4 bytes wide, the necessary allocation for the temporary
array can be up to 128 KiB. Even though this should be fine on typical
systems, we avoid potentially overflowing the stack by using malloc()
instead of alloca().
These certificate requests also contain SHA-1 hashes, which is assumed
in `ike_cert_pre.c::process_certreq()` when enumerating key IDs.
Because the parser allocates a separate chunk for the data and the
enumerator doesn't read beyond that chunk's length after the first
iteration, only lengths between 1 and 19 are problematic (0 doesn't
cause an enumeration because chunk_empty is assigned).
Whether the OOB read then can cause a segmentation fault depends on the
allocator, its alignment rules, and its minimum overhead. For instance,
with glibc on a typical 64-bit system (8 bytes for pointers and size_t),
the alignment is 16 bytes and the minimum allocated size is 32 bytes,
with typically 24 that are technically available for data, even if only
0 bytes are allocated (as returned by `malloc_usable_size()`). So with
an allocation between 1 and 19, we can always safely read 20 bytes.
Assuming that other allocators behave similar for small allocations, it
seems unlikely that this causes a crash.
Fixes: 15612b3a42 ("Add support for IKEv2 OCSP extensions (RFC 4806)")
`xmlNodeGetContent()` returns `NULL` if `child` is `NULL`, which causes
a segmentation fault in `chunk_from_str()`.
Fixes: ec1eab0319 ("fixed XML parsing of TNCCS 1.1 ReasonString message")
The RFC only allows that the number of fragments increases (if the
sender reduces the MTU).
Not enforcing this before could cause early reassembly as the trigger was
that the number of received fragments matches the total count of the
current packet (which was a bit weird anyway). Only an active MITM could
trigger this as individual fragments are encrypted and authenticated.
This mainly intended as defense-in-depth measure to avoid parsing
massively nested structures that could cause a call stack overflow due
to the massive recursion. In particular PKCS#7 signed data is prone to
this as these can be nested basically infinitely. When used in IKEv1 via
ENC_PKCS7_WRAPPED_X509 CERT payloads, our default of 10000 bytes for IKE
messages guards against this, but that's configurable and there might be
a chance for some bug that triggers problematic recursive parsing for
smaller input.
The upper limit is chosen arbitrarily, but there are currently no known
cases that require a depth of more than 10 levels.
If nothing was read from the message, the previous code could result in
a crash depending on where `ext.ptr` pointed to, as determined by the
current stack contents. Since TLS 1.3 is still disabled by default and
this is usually used for TLS-based EAP methods after validating the
IKEv2 server's certificate, the real world impact seems relatively low.
Fixes: 9ef46cfaf9 ("tls-peer: Mutual authentication support for TLS 1.3")
These attributes contain a 16-bit length field for the actual length of
the data in bits or bytes, as compared to the length in 4-byte blocks in
the attribute header. The previous code didn't correctly account for the
length of the fixed header (4 bytes) when it compared the parsed length
to the length in the header. This could cause an out-of-bounds read of
up to four bytes beyond the end of the attribute/message.
Fixes: f8330d0395 ("Added a libsimaka library with shared message handling code for EAP-SIM/AKA")
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.
Fixes: 79f2102cb4 ("implemented server side support for EAP-TTLS")
Fixes: CVE-2026-25075
To make the default strongswan.conf, with `load_modular` enabled, work
if charon itself is not built, we enable generating the charon-specific
snippets also for the two other daemons that fall back on reading
options from the `charon` section.
Lukas Johannes Möller