Because `assess()` returns a `status_t`, `FALSE` is interpreted as
`SUCCESS`. So a failure while processing PB-TNC batches terminated
the process successfully.
Fixes: 1e92d5f114 ("Process PB-TNC batches received via PT-TLS asynchronously")
Note that wolfSSL before 5.9.2 required building with
WOLFSSL_ECDHX_SHARED_NOT_ZERO, which was added with 5.3.0, to get and
explicit check. Since the plugin validates the public key, the test case
fails nonetheless.
While RFC 7748 states implementations MAY perform such a check, e.g.
TLS 1.3 explicitly requires it (RFC 8446, section 7.4.2).
Fixes: 7f9bfacd5a ("curve25519: Add a plugin providing Curve25519 DH using backend drivers")
Using the same `hasher_t` instance from different threads concurrently
is not safe. The underlying implementation might e.g. use a single
shared state for multiple API calls within `get_hash()` (e.g. the openssl
plugin does that).
Fixes: 007c47088c ("Implemented permanent certificate coupling plugin")
The WC_RNG instances are potentially shared between different threads
as private key objects are refcounted. This may corrupt their internal
state as they are not thread-safe.
For ECDSA, using separate instances for each signing operation has some
performance impact, but for signature operations that should be fine.
The implementation for RSA uses mutexes. That's due to the weird API.
While RNG instances can be passed for signing and encryption (probably
because they are also required for padding/salt besides blinding), they
can't for verifying and decryption. The latter use an RNG instance that
has to be set on the key object before calling these operations. So we
could potentially split the strategy, but to keep this consistent within
the RSA implementation, just continue with the shared RNG but use a
mutex around the API calls.
Fixes: c92eade82c ("wolfssl: Add wolfSSL plugin for cryptographic implementations")
The `aead_t` interface states that `decrypt()` only allocates a plaintext
buffer if successful, so callers might not free it if the call failed.
Fixes: 313811b72d ("aesni: Add a GCM AEAD based on the AES-NI key schedule")
If an `aead_t` implementation incorrectly allocates memory if the
decryption/ICV verification failed, this avoids a leak. Unfortunately,
many implementations actually did that.
Fixes: 24a8d1253f ("libipsec: Wrap traditional algorithms in AEAD wrapper")
This was added with 5ce3c9b15a ("watcher: Rebuild fdset when select()
fails"), i.e. before switching to poll(), solely to suppress errors when
FDs are closed and select() would return with an error. With poll()
this should not happen result in an error (it potentially indicates this
via POLLNVAL in revents of that FD in the array).
Because the flag was not consistently changed/read with the mutex held,
some analysis tools got confused and imagined wild deadlock scenarios.
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)")
This does not seem to work on these runners. Tried setting
dataflowMemoryLimit, but that only seems to affect the analysis (which
causes a warning: "Taint analysis was stopped early due to low memory.
The analysis may not have explored the whole program.") not the
post-processing that evidently causes the runner to get killed due to
OOM (there is no explicit error, but in the debug log we see "The runner
has received a shutdown signal", which apparently can indicate OOM
issues).
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).
This fixes handling of SIGINT (CTRL+C) so we don't continue with the
next potentially hanging command (e.g. several pings after another that
fail because a required SA didn't come up correctly). We try to kill
the PID for every SIGINT in case the first one arrived before the
subshell was started. The `TDUP_<host>` variables are not updated in
the main shell when `stop_tcpdump` is called from the subshell, so
it is called redundantly during the cleanup (removed the useless guard
there and use pkill to suppress any messages if no process is found).
If we get interrupted during one of the init/cleanup WAIT_FOR waits,
we just let them running in the background when exiting the script.
They should generally not do any harm (and be terminated once the next
run is attempted, which might require a rebuild during development
anyway).
Since a103f3a284 ("testing: Add options to only run pre- or posttest
scripts of a scenario") we can now also skip the remaining steps easily.
However, we do run the posttest script to clean up properly (e.g.
terminate the daemons, restore firewall rules etc.). That's also why
it's not running in a subshell.
These are apparently not necessary anymore and since there are often
sync issues (package version mismatch if security fixes are shipped
because there is no *-security suite in the ddebs repo), lets not
install them anymore.
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.
Tobias Brunner