The presence of a peer ID is enforced by the message rules for ME_CONNECT,
this just mirrors the safety check also present in `process_r_ms()`.
Fixes: d5cc175833 ("experimental P2P-NAT-T for IKEv2 merged back from branch")
These were never correct. And the first referenced commit, unfortunately,
just simplified the incorrect code.
Fixes: 08a3ee0cce ("bus: Change ike_update() signature and only call it once")
Fixes: b8973b2661 ("connmark: Add CONNMARK rules to select correct output SA based on conntrack")
The `transaction` variable was previously still set to the one that
was enumerated last even if the received DHCP OFFER did not match
it. So the transaction was incorrectly modified. Once the real
DHCP OFFER would arrive, it would get modified again, but it could
allow adding unintended DNS servers.
When initiating a Child SA with a CREATE_CHILD_SA exchange, the initial
exchange could fail with an INVALID_KE_PAYLOAD notify. The initiation
would then get retried from scratch (the `child_sa_t` object is destroyed
and a new one created). If it fails again, the previous code didn't
signal the waiting thread. If it did not set a timeout, it would wait
indefinitely.
Using a different `status_t` value avoids any confusion with NEED_MORE
that's used to indicate that the callback returned FALSE (e.g. if the
IKE_SA would go down before concluding the retry).
Fixes: c39b0c883d ("controller: Keep following initiate() if the first DH guess was wrong")
EAP-PEAP transports results as separate AVPs, we expect one after the
first phase 2 authentication (if not using certificates). However, with
the previous caching of the result of that, the client could then send
another confirmation as response to the EAP-TNC request to skip it.
Since no group membership is set if EAP-TNC is not complete, it shouldn't
really affect its outcome, though.
Fixes: 1be296dfb2 ("implemented the PEAP tunneling protocol as an EAP plugin")
The entry was updated and the previous EAP method and IKE SA destroyed
under a read lock, which is not safe (there could be threads in
get_state(), or even some that called it before and now still hold
that read lock while interacting with the EAP method).
Fixes: 37884ab10f ("Add locking to TNC-PDP connections")
As `tv_sec` is a `time_t`, i.e. typically 64 bits, assigning the result
of `htonl()` leaves the upper 32 bits zero. Copying from the
`sizeof(time_t) - 4` offset then copies those zeroes on little-endian
systems, which is not what was intended according to the comments.
Another issue was that the type of `tv_usec`, `suseconds_t`, is typically
a `long`, i.e. signed, so shifting the maximum value 0x000f423f (999'999)
by 12 bits technically overflows this. The cast fixes that.
Fixes: 1aba82bfd7 ("eap-aka-3gpp: Add plugin that implements 3GPP MILENAGE algorithm in software")
Basically the same as the previous commit.
Fixes: edcb2dd35b ("Moved reauth/pseudonym functionality from eap-sim-file to separate plugins, usable by any SIM/AKA backend")
This also protects access to the RNG, which is not always thread-safe.
Fixes: edcb2dd35b ("Moved reauth/pseudonym functionality from eap-sim-file to separate plugins, usable by any SIM/AKA backend")
Due to the `sleep()` call, a continuous stream of failed authentication
attempts can potentially exhaust the thread pool. While delays can also
happen due to RADIUS or DHCP on the server side, this can directly be
triggered by clients. It's questionable whether the delay ever had the
intended effect. But since the retry functionality is also quite
strange, let's just remove it so retries will require creating an IKE_SA
from scratch. To avoid leaking much of a timing difference if no secret
is found now that the two second delay is gone, we do the calculations
with a dummy NT hash.
Fixes: f98cdf7a47 ("adding plugin for EAP-MS-CHAPv2")
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")
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 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")
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")
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.
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)")
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.
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
Tobias Brunner