In non-blocking mode, the previous code set `in_done` to -1 (SIZE_MAX)
if `recv()` would block and nothing was read yet. If this was followed
by a call to `write()` and `process()` is called and actually processed
application data, the length calculation in the callback underflows and
`memcpy()` would write to `in.ptr + SIZE_MAX`. Since `read()` already
sets `errno` to `EWOULDBLOCK` and returns -1 if `in_done` is 0, the
removed check was redundant anyway.
Also, the buffer from the previous `read()` call might not be valid
anymore when `write()` is called (e.g. `splice()` uses the same buffer
for both, and the buffer could even be defined on a now invalid stack
frame of the function that called `read()` previously). Clearing the
data avoids that and ensures the application data is cached until the
next call to `read()`.
However, triggering this is rather difficult as `write()` should only
reach `recv()` while the handshake isn't complete and until then
`process_application()` doesn't accept application data. But if the
handshake is completed during a call to `write()` that follows a
non-blocking read and data immediately arrives, it's theoretically
imaginable. This scenario is highly unlikely on a TLS server, which
starts the process with a call to `read()` that then basically loops
until the handshake is done. Even if multiple calls are required, the
server will generally not call `write()` before it received application
data. And any calls to `write()` afterwards do not reach `recv()`
anymore (unless no data to send was passed, which would be weird, or
maybe for some weird corner case that lets `build()` fail before all
outbound application data was processed).
The two fields were swapped in the calculation and the new code also
avoids overflowing on 32-bit systems.
Fixes: 4cb0e1bb76 ("Added basic support for PGP certificates (no trust relationships yet)")
Because the CFLAGS applied to the whole plugin, the compiler could
"optimize" the boilerplate plugin code, which could then cause a SIGILL
on hardware that doesn't support such instructions. This change makes
sure only the actual AES implementation is compiled like that, which
would then not get registered depending on the CPU feature detection.
If there are lots of SAs to be synced, the default might be too low
and messages and SAs get dropped. The new default is already 8 MiB,
which should work fine for lots of SAs. The code mirrors the one in
the kernel-netlink plugin (but with a guard around SO_RCVBUFFORCE, even
though this plugin is mostly used on Linux as well).
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 418dbd6243
("cloning %any ID without zero-byte memleak") and identities that trigger
this can be created since 86ab5636c2 ("support for @#hex ID_KEY_ID
identification_t"), it was the referenced commit that made the length
check problematic.
Fixes: 2147da40a5 ("simplified identification_t.clone() using memcpy")
Fixes: CVE-2026-47895
It seems that 18a94525a7 was a bit hasty. Apparently, it's still the
case that there were reports (at least in some test scenarios). Luckily,
the new facility added in the previous commit allows us to whitelist
these allocations without having to ignore all unknown memory.
With glibc, there is an issue if TZ is not set, which causes a change
of the internally cached TZ value. Because the original value was
cached before LD was active via `init_static_allocations()`, the memory
is freed as unknown memory later. This change allows whitelisting
a function that might free such memory (tzset() only for now).
This prevents an OOB read if the AT_RAND data is shorter than the
expected 16 bytes.
The check for AT_AUTN is changed for consistency even though its length
is already enforced by the parser (for AT_RAND it isn't because EAP-SIM
expects a length of either 32 or 48 bytes).
Fixes: aea334ec1c ("Splitted EAP-AKA in peer and server implementations, use libsimaka helper library")
When resolving the remote host, we first determine if a particular
address family is preferred locally. With `0.0.0.0` that's IPv4, with
`%any` that's not the case. So we use the latter to allow resolvers
to return an IPv6 address.
This allows clients to distinguish between algorithms of different
transform types more easily. The names are similar to those used
when returning the algorithms of the selected proposal in list-sas (except
for `ke` instead of `dh` and `sn` instead of `esn` to reflect the
latest IETF/IANA changes).
Because the `derived` flag was not reset (it's set after the initial
IKE_SA_INIT exchange), no keys would get derived when sending
IKE_INTERMEDIATE during the next try. As there is then no `aead_t`
available, encrypting the message would fail and the initiation would
remain stuck.
Fixes: 0d49ddec2e ("ike-init: Add support for multiple key exchanges")
While the validity of a pre-trusted certificate for which an issuer is
found is enforced via `check_certificate()`, the validity of such a
certificate in an incomplete trust chain, or rather that of the last
certificate in such a chain, was not enforced. This fixes that
inconsistency.
In a targeted request, the software ID is provided by the IMV. If no
database is used (which is not the recommended setup), the ID is not
validated and could potentially contain special characters. With the
previous command string construction and use of popen(), which runs a
shell, that could potentially allow running arbitrary commands.
Unlike `struct ifreq` that's used for IPv4, `struct in6_ifreq` contains
not a `struct sockaddr[_in6]` but only a `struct in6_addr`.
Setting addresses like this is currently not used on Linux (the feature
was added to install virtual IPs on FreeBSD/macOS).
Fixes: fccc76449d ("tun-device: Fix handling of IPv6 addresses")
Keys loaded via generic loader (KEY_ANY) or from a PKCS#12 file (or an
engine) don't go through the openssl_ec_private_key_load() constructor
that checks for explicit parameters.
This was broken since the Botan 3 release, which removed the EMSA1
class and the define. The "EMSA1()" wrapper when signing/verifying is
technically not necessary anymore since then (it's deprecated but still
accepted). But to still support Botan 2, we keep that in for now.
The missing parentheses around the additions when calculating optlen
in the previous code can cause an out-of-bound read of up to 228 bytes
if no DHCP_OPTEND is found in the message (the calculation basically
evaluated to `- 20 + 8 + 240`).
Since the buffer for the received packet (via pf_handler_t) is located
on the stack, this shouldn't cause much of an issue in practice.
The leak detective doesn't wrap this function and calling the original
causes unknown memory frees and even segmentation faults. This is now
triggered with OpenSSL 4 as the implementation of ECP256 uses
OPENSSL_aligned_alloc_array().
Setting a custom memory functions forces OpenSSL to implement aligned
allocations internally, using the registered allocation function.
Using the return value of i2d_* directly as input of chunk_alloc imposes
the risk of creating an invalid chunk when the return value of the i2d_*
function is -1. The openssl_i2chunk macro is meant to avoid this.
Signed-off-by: Thomas Egerer <thomas.egerer@secunet.com>
Tobias Brunner