Such a recursive call occurs when sorting the array of Child SAs inside
an IKE SA that causes comparisons of the child configs and their
proposals, which in turn creates a merged array of all transform types
and that uses array_sort() and array_bsearch().
Closesstrongswan/strongswan#2926
Fixes: 8e7f379f71 ("ike-sa: Sort CHILD_SAs by CPU ID")
We explicitly use untoh16() so this warning isn't relevant:
ip_packet.c:313:42: error: taking address of packed member 'ip_len' of class or structure 'ip' may result in an unaligned pointer value [-Werror,-Waddress-of-packed-member]
Clean up leak-detective whitelist for newer Botan versions but add
`botan_private_key_load` as `botan_privkey_load*` won't show up anymore
without bfd-backtraces due to inlining if we don't call it directly.
Ref: https://github.com/randombit/botan/discussions/4868
This ensures we access the socket as user who NM ran the auth-dialog for,
especially for system-wide connections where the connection does not
mention a user.
We also make sure we don't use the cached socket and user of a previous
connection attempt, because system-wide connections might be used by
different users.
This prevents an attack similar to the one fixed previously where a
user passes the path to credentials of another user, in this case the
path to the agent socket of that user.
This ensures that only certificates/private keys accessible by the
configured user are accessed and prevents attackers from misusing
other user's credentials.
Also removed setting NM_VERSION_MIN_REQUIRED, which suppresses deprecation
warnings that were added with newer API versions, and
NM_VERSION_MAX_ALLOWED, which warns if using functions added in newer
API versions, so we always build against the latest API available.
But we check explicitly for the required function so this works with
older NM versions and automatically will use it if the function is
backported.
Note that we can't use BUILD_FROM_FILE to read the temporary files as that
uses mmap() which SELinux policies prevent us from using at the location
these files are stored ([/var]/run/NetworkManager/cert/).
Fixes: CVE-2025-9615
Some (Windows) peers have been seen to initiate a second rekeying for the
same Child SA. Presumably, this happens if a rekey request from us for
the same old Child SA arrives while it waits for the response to its
first rekey request. Once we receive the delete for the old SA, we
conclude the rekeying with the second replacement. However, the first
replacement remained linked to the old SA. So this change prevents a
crash once the peer sends a delete for that first replacement (which it
seems to do after about 5 minutes).
References strongswan/strongswan#2944Closesstrongswan/strongswan#2945
This ensures that packets on sun are processed on a particular CPU and
not randomly on one, which causes expected SAs not to get created or
other weird things.
Also remove the --enable-md4 option. We never supported MD4 via wolfSSL,
as it's not available via the hash API we use (would require explicit
MD4-specific functions and structures).
Increases buffers in settings and swanctl to allow longer connection
names (up to the limit of 256 characters imposed by VICI). The limit
for names is now also enforced when generating VICI messages.
Closesstrongswan/strongswan#2936
The buffer size for individual parts of a key now match the maximum length
of names in VICI. The full pattern should accommodate several long names
(e.g. for connections and child connections in swanctl) even if no
printf-specifiers are used.
Combines concurrent requests for the same CRL URI by multiple threads.
So only the first thread actually fetches it, the others wait for that
result. This is particularly helpful if the CRL can currently not
be fetched due to DNS or HTTP/LDAP timeouts as it prevents each thread
from having to wait for the complete timeouts, which reduces the number
of SAs that can concurrently be established.
A negative result is cached for a while (currently 3 times the fetch
timeout, i.e. 30 seconds by default) so requests can fail quickly and
threads can continue establishing SAs if they use a relaxed revocation
policy.
Closesstrongswan/strongswan#2918
If a CRL server is unresponsive, all threads trying to fetch this CRL will
block execution. If a recent previous attempt to fetch the CRL failed, it
is likely that it will fail again. While it makes sense to retry fetching
the CRL on demand with one thread, it hardly does to block additional
threads while the first one is blocked during the fetch.
So remember the timestamp of the last CRL fetch failure per URL, and do
not block more than one thread in the CRL fetch for some time. This time
is a multiple of the configured fetch timeout, so that it works well for
any configured value. With the default configuration, a failing CRL fetch
will impact concurrent CRL fetches for the same URL for 30s.
When handling many connection attempts from peers using the same CA, a slow
or non-responsive CRL distribution point can lead to concurrent fetches of
the same CRL by multiple threads. This is not only inefficient, but results
in all threads blocking for the full fetch timeout, potentially blocking
all threads in the pool.
As a first step, synchronize CRL fetches using a global mutex and a per-URL
condvar, so threads can wait for the CRL if another is already fetching it.
This reduces the number of useless concurrent CRL fetches, and allows threads
joining the party late to get blocked only until the first fetch completes
or times out.
The URL entry is preserved in the hashtable after completing the fetch.
This will allow subsequent optimizations to store the last fetch result
and act accordingly. The CRL itself is not, as CRLs can be rather large
and caching them can be done using existing mechanisms controlled via
corresponding options.
Before adding stateful CRL fetching extensions, refactor CRL fetching to
a helper class for better separation. While there are currently no plans
to extend OCSP fetching, move it as well for consistency.
As future commits will require shared state during fetch operations, a common
context is required. So pass along the "this" parameter in various revocation
functions.
Using FrameLayout for the settings instead of the recommended
FragmentContainerView because the latter makes handling insets more
complicated (fitsSystemWindows doesn't work as the fragment is responsible
for handling insets but how that should work with PreferenceFragmentCompat
is unclear).
Fixes: 2404b2bee6 ("android: Apply UI changes for edge-to-edge views in Android 15+")
This fixes the vulnerability in the eap-mschapv2 plugin and an issue
with the filename of log files. In the released app, the OpenSSL version
is also increased in order to support ML-KEM.
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.
Fixes: f98cdf7a47 ("adding plugin for EAP-MS-CHAPv2")
Fixes: CVE-2025-62291
While wrong, this isn't an issue in practice as AUTH_RESPONSE_LEN is
long enough that subtracting HEADER_LEN is fine.
Fixes: f98cdf7a47 ("adding plugin for EAP-MS-CHAPv2")
Tobias Brunner