crypto/sleep.c: avoid returning early due to signal
On POSIX systems, sleep/usleep/nanosleep may return early due to arrival
of a signal, and OSSL_sleep does not report that, so it is assumed that
it cannot return early. Fix that by introducing a loop that checks
the remaining time and sleep some more if the time has not passed;
that also solves the issue of limited sleeping time on some systems.
Signed-off-by: Eugene Syromiatnikov <esyr@redhat.com> Reviewed-by: Neil Horman <nhorman@openssl.org> Reviewed-by: Saša Nedvědický <sashan@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/28193)
Reviewed-by: Neil Horman <nhorman@openssl.org> Reviewed-by: Tim Hudson <tjh@openssl.org> Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/28136)
Reviewed-by: Neil Horman <nhorman@openssl.org> Reviewed-by: Tim Hudson <tjh@openssl.org> Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/28136)
sashan [Mon, 4 Aug 2025 07:32:51 +0000 (09:32 +0200)]
- add --no-check-certificate option to wget, pointed out by @esyr
Reviewed-by: Neil Horman <nhorman@openssl.org> Reviewed-by: Tim Hudson <tjh@openssl.org> Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/28136)
the rpki-client external test should use relase version not a master branch on github
@botovq asked me not to use master branch of rpki-client. This will keep CI-run
green regardless of what happens in rpki-client active development branch.
Once new version of rpki-client will be released we will just update the
test here to fetch new msater version.
Reviewed-by: Neil Horman <nhorman@openssl.org> Reviewed-by: Tim Hudson <tjh@openssl.org> Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/28136)
Neil Horman [Thu, 7 Aug 2025 13:50:58 +0000 (09:50 -0400)]
Fix failure checking on rcu_read_lock
during memfail testing:
https://github.com/openssl/openssl/actions/runs/16794088536/job/47561223902
We get lots of test failures in ossl_rcu_read_lock. This occurs
because we have a few cases in the read lock path that attempt mallocs,
which, if they fail, trigger an assert or a silent failure, which isn't
really appropriate. We should instead fail gracefully, by informing the
caller that the lock failed, like we do for CRYPTO_THREAD_read_lock.
Fortunately, these are all internal apis, so we can convert
ossl_rcu_read_lock to return an int indicating success/failure, and fail
gracefully during the test, rather than hitting an assert abort.
Fixes openssl/project#1315
Reviewed-by: Paul Yang <paulyang.inf@gmail.com> Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com> Reviewed-by: Paul Dale <ppzgs1@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/28195)
Neil Horman [Thu, 7 Aug 2025 13:16:11 +0000 (09:16 -0400)]
Fix failure checking on thread_local storage assignment in rand_lib
The new malloc failure test caught an asan error in this code:
Direct leak of 40 byte(s) in 1 object(s) allocated from:
2025-08-07T03:22:20.3655117Z #0 0x7fb88d8fd9c7 in malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:69
2025-08-07T03:22:20.3655796Z #1 0x5584f0e4670a in CRYPTO_malloc crypto/mem.c:211
2025-08-07T03:22:20.3656291Z #2 0x5584f0e4679d in CRYPTO_zalloc crypto/mem.c:231
2025-08-07T03:22:20.3657040Z #3 0x5584f11c4c10 in EVP_RAND_CTX_new crypto/evp/evp_rand.c:353
2025-08-07T03:22:20.3657656Z #4 0x5584f0e93b27 in rand_new_drbg crypto/rand/rand_lib.c:666
2025-08-07T03:22:20.3658289Z #5 0x5584f0e949d0 in rand_get0_public crypto/rand/rand_lib.c:843
2025-08-07T03:22:20.3658914Z #6 0x5584f0e9305b in RAND_bytes_ex crypto/rand/rand_lib.c:490
2025-08-07T03:22:20.3659486Z #7 0x5584f0b2405f in SSL_CTX_new_ex ssl/ssl_lib.c:4191
2025-08-07T03:22:20.3660183Z #8 0x5584f0ae313c in create_ssl_ctx_pair test/helpers/ssltestlib.c:958
2025-08-07T03:22:20.3660871Z #9 0x5584f0adeaf6 in do_handshake test/handshake-memfail.c:56
2025-08-07T03:22:20.3661539Z #10 0x5584f0adee50 in test_alloc_failures test/handshake-memfail.c:125
2025-08-07T03:22:20.3662161Z #11 0x5584f0cd9da8 in run_tests test/testutil/driver.c:342
2025-08-07T03:22:20.3662664Z #12 0x5584f0cda9e5 in main test/testutil/main.c:31
2025-08-07T03:22:20.3663450Z #13 0x7fb88d42a1c9 (/lib/x86_64-linux-gnu/libc.so.6+0x2a1c9) (BuildId: 282c2c16e7b6600b0b22ea0c99010d2795752b5f)
2025-08-07T03:22:20.3664630Z #14 0x7fb88d42a28a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2a28a) (BuildId: 282c2c16e7b6600b0b22ea0c99010d2795752b5f)
2025-08-07T03:22:20.3666608Z #15 0x5584f0ade864 in _start (/home/runner/work/openssl/openssl/test/handshake-memfail+0x22a864) (BuildId: 19659a44d8bed2c082918d25425f77e3a98df534)
It occurs because when rand_get0_public/rand_get0_private sets an
EVP_RAND_CTX object in its thread local storage, it neglects to check
the return code of the operation, which may fail when the associated
sparse array is expanded.
fix it by checking the return code and failing the get0_[public|private]
operation so the failure is graceful.
Fixes openssl/project#1315
Reviewed-by: Paul Yang <paulyang.inf@gmail.com> Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com> Reviewed-by: Paul Dale <ppzgs1@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/28195)
OPENSSL_secure_malloc.pod: articulate possibly non-secure pointer being returned
The semantics of OPENSSL_secure_[mz]alloc is somewhat unorthodox,
as it silently return a pointer to non-secure memory if the arena
is not initialised, which, while mentioned in the DESCRIPTION, is not
clear from reading the pertaining part of the RETURNING VALUE section alone;
explicitly state that the memory may be allocated by OPENSSL_calloc instead
if the secure heap is not initialised.
Signed-off-by: Eugene Syromiatnikov <esyr@openssl.org> Reviewed-by: Saša Nedvědický <sashan@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Paul Dale <ppzgs1@gmail.com> Reviewed-by: Neil Horman <nhorman@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/28059)
crypto/mem.c: don't use aligned_alloc in CRYPTO_aligned_alloc
The original C11 specification is pretty weird: it specifies that the size
must be a multiple of alignment (rendering it useless for small page-aligned
allocations that, for example, might be useful for RDMA) and until DR460[1]
it was UB in failing to do so (as it is with OPENSSL_ligned_alloc() calls
in alloc_new_neighborhood_list() on 32-bit systems, for example).
Moreover, it has arguably not been used much before, as all supported POSIX
systems have at least POSIX 2001 compatibility level nowadays,
Windows doesn't implement aligned_alloc() at all (because implementation
of free() in MS CRT is unable to handle aligned allocations[2]),
and _ISOC11_SOURCE is a glibc-specific feature test macro.
There are some *.inc already in the repository, mostly in demos/tests
and related to some algorithm implementations. Introduction
of array_alloc.inc has made including these files in the tags generation
even more pertinent, so they are included now.
Also, this commit explicitly marks *.h files as containing C code,
overriding universal-ctags default of interpreting them as C++/ObjectiveC
ones.
Suggested-by: Neil Horman <nhorman@openssl.org> Signed-off-by: Eugene Syromiatnikov <esyr@openssl.org> Reviewed-by: Saša Nedvědický <sashan@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Paul Dale <ppzgs1@gmail.com> Reviewed-by: Neil Horman <nhorman@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/28059)
Such routines allow alleviating the need to perform explicit integer
overflow check during allocation size calculation and generally make
the allocations more semantic (as they signify that a collection
of NUM items, each occupying SIZE bytes is being allocated), which paves
the road for additional correctness checks in the future.
Signed-off-by: Eugene Syromiatnikov <esyr@openssl.org> Reviewed-by: Saša Nedvědický <sashan@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Paul Dale <ppzgs1@gmail.com> Reviewed-by: Neil Horman <nhorman@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/28059)
crypto/ec/ecp_nistp256.c: use OPENSSL_zalloc instead of malloc+memset
Complements: b51bce942023 "Add and use OPENSSL_zalloc" Signed-off-by: Eugene Syromiatnikov <esyr@openssl.org> Reviewed-by: Saša Nedvědický <sashan@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Paul Dale <ppzgs1@gmail.com> Reviewed-by: Neil Horman <nhorman@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/28059)
GAlvare [Fri, 2 May 2025 16:57:22 +0000 (11:57 -0500)]
Fixes for build failures on OS X 10.4 Tiger
Also added darwin8-ppc-cc and darwin8-ppc64-cc build configurations for
handling OS X 10.4 PowerPC specific configuration options, specifically
disabling async by default.
Reviewed-by: Neil Horman <nhorman@openssl.org> Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de> Reviewed-by: Paul Dale <ppzgs1@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/27578)
Neil Horman [Mon, 4 Aug 2025 22:29:52 +0000 (18:29 -0400)]
Ensure that the largest_pn values are migrated to our channel qrx
Recently, our overnight QUIC interop runs began failing in CI when an
openssl server was tested against an ngtcp2 client:
https://github.com/openssl/openssl/actions/runs/16739736813
The underlying cause bears some explination for historical purposes
The problem began happening with a recent update to ngtcp2 in which
ngtcp2 updated its wolfssl tls backend to support ML-KEM, which caused
ngtcp to emit a client hello message that offered several groups
(including X25519MLKEM768) but only provided a keyshare for x25519.
This in turn triggered the openssl server to respond with a hello retry
request (HRR), requesting an ML-KEM keyshare instead, which ngtcp2
obliged. However all subsequent frames from the client were discarded by
the server, due to failing packet body decryption.
The problem was tracked down to a mismatch in the initial vectors used
by the client and server, leading to an AEAD tag mismatch.
Packet protection keys generate their IV's in QUIC by xoring the packet
number of the received frame with the base IV as derived via HKDF in the
tls layer.
The underlying problem was that openssl hit a very odd corner case with
how we compute the packet number of the received frame. To save space,
QUIC encodes packet numbers using a variable length integer, and only
sends the changed bits in the packet number. This requires that the
receiver (openssl) store the largest received pn of the connection,
which we nominally do.
However, in default_port_packet_handler (where QUIC frames are processed
prior to having an established channel allocated) we use a temporary qrx
to validate the packet protection of those frames. This temporary qrx
may be incorporated into the channel in some cases, but is not in the
case of a valid frame that generates an HRR at the TLS layer. In this
case, the channel allocates its own qrx independently. When this
occurs, the largest_pn value of the temporary qrx is lost, and
subsequent frames are unable to be received, as the newly allocated qrx
belives that the larges_pn for a given pn_space is 0, rather than the
value received in the initial frame (which was a complete 32 bit value,
rather than just the changed lower 8 bits). As a result the IV
construction produced the wrong value, and the decrypt failed on those
subsequent frames.
Up to this point, that wasn't even a problem, as most quic
implementations start their packet numbering at 0, so the next packet
could still have its packet number computed properly. The combination
of ngtcp using large random values for initial packet numbers, along
with the HRR triggering a separate qrx creation on a channel led to the
discovery of this discrepancy.
The fix seems pretty straightforward. When we detect in
port_default_packet_handler, that we have a separate qrx in the new
channel, we migrate processed packets from the temporary qrx to the
canonical channel qrx. In addition to doing that, we also need to
migrate the largest_pn array from the temporary qrx to the channel_qrx
so that subsequent frame reception is guaranteed to compute the received
frame packet number properly, and as such, compute the proper IV for
packet protection decryption.
Fixes openssl/project#1296
Reviewed-by: Saša Nedvědický <sashan@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/28115)
crypto/threads_pthread: rewrite contention data storage to per-tid
This eliminates locking during writing out of the lock contation report
data, which claws back some of the lost performance degradation imposed
by the lock contention reporting instrumentation:
[Without -DREPORT_RWLOCK_CONTENTION]
~/dev/perftools/source$ ./evp_fetch 100
Average time per fetch call: 4.502162us
~/dev/perftools/source$ ./evp_fetch 200
Average time per fetch call: 8.224920us
[Before]
~/dev/perftools/source$ ./evp_fetch 100
Average time per fetch call: 13.079795us
~/dev/perftools/source$ ./evp_fetch 200
Average time per fetch call: 23.420235us
[After]
~/dev/perftools/source$ ./evp_fetch 100
Average time per fetch call: 6.557428us
~/dev/perftools/source$ ./evp_fetch 200
Average time per fetch call: 13.415148us
The downside is that it produces a file for each TID, which floods
the working directory with debug files, but that mich be an acceptable
trade-off.
Reviewed-by: Neil Horman <nhorman@openssl.org> Reviewed-by: Saša Nedvědický <sashan@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/27983)
crypto/threads_lock_contention: factor out obtaining the stack traces data pointer
It also drops the premature initalisation of it in
ossl_init_rwlock_contention_data(), deferring it to on-demand one
in ossl_rwlock_{rd,wr}lock(), which seems to shave some of the incurred
overhead:
[Before]
~/dev/perftools/source$ ./evp_fetch 100
Average time per fetch call: 16.944004us
~/dev/perftools/source$ ./evp_fetch 200
Average time per fetch call: 26.325767us
[After]
~/dev/perftools/source$ ./evp_fetch 100
Average time per fetch call: 13.079795us
~/dev/perftools/source$ ./evp_fetch 200
Average time per fetch call: 23.420235us
Signed-off-by: Eugene Syromiatnikov <esyr@openssl.org> Reviewed-by: Neil Horman <nhorman@openssl.org> Reviewed-by: Saša Nedvědický <sashan@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/27983)
Signed-off-by: Nikola Pajkovsky <nikolap@openssl.org> Reviewed-by: Paul Dale <ppzgs1@gmail.com> Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com> Reviewed-by: Neil Horman <nhorman@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/28185)
Neil Horman [Wed, 23 Jul 2025 13:09:05 +0000 (09:09 -0400)]
add a handshake memory failure test
We would like to be able to test our memory failure paths, but forcing
malloc to return NULL at certain points in time.
This test does that, by running a sepcific workload n+1 time. In this
case the workload is a simple ssl handshake.
We run 1 test which sets our malloc wrapper into record mode, in which
it just acts as a pass through to the system malloc call and records the
number of times it was called.
Then we run a second test, which does the same handshake N times, where
N is the number of times malloc was called in the previous test. For
each iteration in i=0..N we fail the ith malloc operation.
We don't check for functional failures in the second test (as we expect
failures), we just want to make sure that (a) we don't crash and (b)
asan doesn't report any errors.
Currently, we get _lots_ of asan failures, but we can use this test to
log issues for that and fix those up.
Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Paul Dale <ppzgs1@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/28078)
Nikolas Gauder [Mon, 4 Aug 2025 21:47:23 +0000 (23:47 +0200)]
ssl/quic/quic_channel.c: Fix endianness of supported versions from received version negotiation packets
Reviewed-by: Neil Horman <nhorman@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/28169)
Nikolas Gauder [Mon, 4 Aug 2025 19:12:35 +0000 (21:12 +0200)]
ssl/quic/quic_port.c: Fix endianness of supported versions in sent version negotiation packets
Reviewed-by: Neil Horman <nhorman@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/28169)
While the majority of the sites assumed 8-wide tabs, at least engines/e_capi.c
assumed 4-wide; in any case it is better to just follow the code style guide
and eliminate them altogether. Some addition changes (namely, curly
brackets in apps/crl.c and apps/req.c, and additional whitespace changes
in apps/s_client.c and test/provider_pkey_test.c) are made to placate
check-format-commit.sh.
Signed-off-by: Eugene Syromiatnikov <esyr@openssl.org> Reviewed-by: Neil Horman <nhorman@openssl.org> Reviewed-by: Paul Dale <ppzgs1@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/28162)
util/perl/OpenSSL/Test.pm: consistently use 4 spaces for indentation
While the majority of the file uses 4 spaces for indentation, some parts
contain 8-wide tabs. Use the spaces for indentation consistently
throughout the file.
Signed-off-by: Eugene Syromiatnikov <esyr@openssl.org> Reviewed-by: Neil Horman <nhorman@openssl.org> Reviewed-by: Paul Dale <ppzgs1@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/28162)
Pauli [Fri, 11 Jul 2025 06:03:12 +0000 (16:03 +1000)]
params: revert error checking when params are duplicated
This is to avoid a change of behaviour even though it is a result of user
error. When params are duplicated, all but the first are ignored and no
error is returned.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com> Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/27923)
projects / thirdparty / openssl.git / log
