clang-22 with enable-asan and enable-ubsan enabled fails with error
crypto/sparse_array.c:93:21: runtime error: call to function alg_copy
through pointer to incorrect function type 'void (*)(unsigned long, void *, void *)'
ossl_sa_##type##_doall(const SPARSE_ARRAY_OF(type) * sa,
void (*leaf)(ossl_uintmax_t, type *))
{
ossl_sa_doall((OPENSSL_SA *)sa,
(void (*)(ossl_uintmax_t, void *))leaf);
}
typed doall(_arg) expect leaf to have type, but generic code is using
void *, and the type-casting cases the error.
Signed-off-by: Nikola Pajkovsky <nikolap@openssl.org>
Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: Eugene Syromiatnikov <esyr@openssl.org>
MergeDate: Sun May 3 15:17:58 2026
(Merged from https://github.com/openssl/openssl/pull/31035)
Instead of needlessly casting const away, simply update the prototype
of ossl_ipaddr_to_asc(), that doesn't modify the passed data in any way
anyway.
Fixes: f584ae959c "Let's support multiple names for certificate verification"
Signed-off-by: Eugene Syromiatnikov <esyr@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.foundation>
Reviewed-by: Frederik Wedel-Heinen <fwh.openssl@gmail.com>
MergeDate: Sat May 2 18:07:19 2026
(Merged from https://github.com/openssl/openssl/pull/31051)
QUIC stack may panic when application calls SSL_get_stream_write_state()
on cocluded QUIC stream onject. The sequence of action which leads
to NULL pointer dereference is as follows:
- application uses SSL_stream_conclude(ssl_stream, 0) to conclude
the stream (let remote peer know no to expect more data)
- application uses SSL_get_stream_write_state(ssl_stream)
to query stream state.
If underlying sstream object is gone by the time when
SSL_get_stream_wtite_state() is called, then application
may see NULL pointer dereference. The underlying sstream
object is freed when FIN sent on beahalf of SSL_stream_conclude()
is ACKed by remote peer.
Reviewed-by: Eugene Syromiatnikov <esyr@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.foundation>
MergeDate: Tue Apr 28 12:35:41 2026
(Merged from https://github.com/openssl/openssl/pull/30913)
Treat method-cache hash table inserts as successful only when they
return 1. This handles allocation/grow failures distinctly from
successful replacement and avoids using temporary QUERY entries after
failed insertion.
Separate cleanup for unlinked temporary QUERY objects from linked
cache entries, and release both the pending cache reference and
caller-visible method reference when deferred providerless cache
insertion fails.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Neil Horman <nhorman@openssl.org>
MergeDate: Tue Apr 28 06:33:15 2026
(Merged from https://github.com/openssl/openssl/pull/30891)
Those function used to be backends for SSL_attach_stream() and
SSL_detach_stream(). Both those functions were removed from
API back 2023. And it does not look like there is a plan
to revive them. This PR removes implementation of stream detach/attach
functions with their tests.
Reviewed-by: Matt Caswell <matt@openssl.foundation>
Reviewed-by: Eugene Syromiatnikov <esyr@openssl.org>
MergeDate: Sun Apr 26 13:26:58 2026
(Merged from https://github.com/openssl/openssl/pull/30956)
Also slightly refactor the ML-KEM version to share the necesasry
defines, and add a daily CI run to check both (presently, for just some
platforms with known working valgrind support).
Reviewed-by: Nikola Pajkovsky <nikolap@openssl.org>
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
MergeDate: Wed Apr 22 07:55:14 2026
(Merged from https://github.com/openssl/openssl/pull/30863)
The macro checked (ZVX_MIN >= offset) which is equivalent to
(offset <= ZVX_MIN), making it true for offsets 0-15 instead of
the intended range [ZVX_MIN, ZVX_MAX] = [15, 23].
The practical effect in hwprobe_to_cap() was inverted:
- Scalar extensions (ZBA..ZKT, offsets 0-14) were incorrectly
treated as vector-dependent and suppressed when VECTOR_CAPABLE
was false, preventing their detection via hwprobe.
- Vector extensions ZVBC..ZVKSH (offsets 16-23) were not treated
as vector-dependent, allowing them to be enabled via hwprobe
even when the V extension was absent.
Fix by changing >= to <= so the macro correctly tests whether
offset falls in [ZVX_MIN, ZVX_MAX].
Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
Reviewed-by: Eugene Syromiatnikov <esyr@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.foundation>
MergeDate: Thu Apr 16 17:03:40 2026
(Merged from https://github.com/openssl/openssl/pull/30713)
CRYPTO_atomic_load_ptr - load a pointer value with relaxed semantics
CRYPTO_atomic_store_ptr - store a pointer value with relaxed semantics
CRYPTO_atomic_cmp_exch_ptr - cmp/exch a pointer with relaxed or acq/rel
semantics
The addition of these functions enables us to better use atomics to
replace read/write locks where we are almost always doing reads
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Nikola Pajkovsky <nikolap@openssl.org>
MergeDate: Tue Apr 14 08:29:30 2026
(Merged from https://github.com/openssl/openssl/pull/30670)
Remove the scid variable entirely from port_default_packet_handler()
and all functions that accept it as a parameter. The scid was never
used meaningfully — cur_remote_dcid is set later during the handshake.
Remove scid parameter from:
- port_bind_channel()
- port_validate_token()
- ossl_quic_channel_on_new_conn()
- ossl_quic_bind_channel()
- ch_on_new_conn_common()
Remove the cur_remote_dcid = *peer_scid assignment in
ch_on_new_conn_common() as it wrote dead data.
CWE-457
Reported-by: Sunwoo Lee <sunwoolee@kentech.ac.kr>
CLA: trivial
Reviewed-by: Saša Nedvědický <sashan@openssl.org>
Reviewed-by: Frederik Wedel-Heinen <fwh.openssl@gmail.com>
Reviewed-by: Tomas Mraz <tomas@openssl.foundation>
MergeDate: Wed Apr 8 10:21:55 2026
(Merged from https://github.com/openssl/openssl/pull/30611)
The EVP_ENCODE_LENGTH macro performs all arithmetic in the type of
its argument. When the argument is int and exceeds approximately
1.6 billion, intermediate results overflow signed int, potentially
wrapping to a smaller positive value rather than a negative one.
In b64_write() (crypto/evp/bio_b64.c), this causes OPENSSL_malloc
to allocate a buffer smaller than the actual encoded output size.
EVP_EncodeUpdate then writes past the end of the undersized buffer.
Changes:
- Cast macro argument to size_t in EVP_ENCODE_LENGTH to prevent
signed integer overflow
- Change encoded_length in b64_write() from int to size_t and add
an explicit overflow sanity check before allocation
- Change return type of evp_encodeblock_int() and
encode_base64_avx2() from int to size_t so that large encoded
output lengths are not truncated
- Update EVP_EncodeUpdate() to use size_t for the encoder return
value accumulator (j), consistent with the existing size_t total
- Add explicit (int) casts in EVP_EncodeBlock() and EVP_EncodeFinal()
where the public API requires int return values
Reviewed-by: Saša Nedvědický <sashan@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.foundation>
MergeDate: Fri Apr 3 14:55:29 2026
(Merged from https://github.com/openssl/openssl/pull/30321)
On Windows, SOCKET is defined as unsigned (UINT_PTR).
In OpenSSL, the socket abstraction uses int, see
discussion in https://github.com/openssl/openssl/issues/7282.
MINGW for some time uses a signed definition of INVALID_SOCKET,
then switched back to unsigned, see for example
https://sourceforge.net/p/mingw-w64/discussion/723797/thread/71522d10/
Currently, it is defined as unsigned, creating many warnings like
warning: overflow in conversion from 'long long unsigned int' to 'int'
changes value from '18446744073709551615' to '-1' [-Woverflow]
*sock = INVALID_SOCKET;
As we use INVALID_SOCKET only in our code, we can safely silence
this warning just by redefining INVALID_SOCKET to signed
(version that is commented out in MINGW headers).
While this is only a workaround, it has been here for years and
allows focus on more important warnings.
Signed-off-by: Milan Broz <gmazyland@gmail.com>
Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: Saša Nedvědický <sashan@openssl.org>
Reviewed-by: Eugene Syromiatnikov <esyr@openssl.org>
MergeDate: Tue Mar 31 00:22:27 2026
(Merged from https://github.com/openssl/openssl/pull/30616)
One thing @npajkovsky noted in our recent discussion about the internal
hash table was that its unfortunate that keys have to be sized for the
maximal use case in our current hashtable code.
We can avoid that.
Introduce a new init mechanism that allows for keys to initalized using
an external buffer that can be setup and marshalled independently of the
key itself. This allows us to only allocate the amount of data needed
for the key, rather than a maximally sized buffer where appropriate and
adventageous.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Saša Nedvědický <sashan@openssl.org>
MergeDate: Tue Mar 24 16:23:07 2026
(Merged from https://github.com/openssl/openssl/pull/30254)
One thing we can do to speed up hash table lookups is to cache/reuse
computed hash values when interrogating a hash table multiple times in
rapid succession.
We follow this pattern frequently when using hashtables:
value = lookup_hash(key)
if (value == NULL)
value = new_value()
insert_to_hash(key, value)
Note that we use the same key for the lookup and the insert. So if we
had a way to preserve the value this key hashed to, we can avoid having
to do a second hash computation during the lookup.
These new macros give us that. The HT_KEY structure now stores the
computed hash value in the key, which can be extracted and reused by the
caller with the HT_INIT_KEY_CACHED macro. When set, the cached hash
value is used, rather than needing to recompute the hash for any
subsequent operations
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Saša Nedvědický <sashan@openssl.org>
MergeDate: Tue Mar 24 16:23:05 2026
(Merged from https://github.com/openssl/openssl/pull/30254)
Add client-side GREASE (Generate Random Extensions And Sustain
Extensibility) support per RFC 8701. When SSL_OP_GREASE is set,
the TLS client injects reserved 0x?A?A-pattern values into the
ClientHello to prevent ecosystem ossification caused by servers
that reject unknown values.
GREASE values are injected into:
- Cipher suites (prepended)
- Supported versions extension (prepended)
- Supported groups extension (prepended)
- Signature algorithms extension (appended)
- Key share extension (prepended, 1 zero byte)
- Two standalone extensions (one empty, one with 1 zero byte)
The implementation uses lazy-seeded random values that remain
consistent across HelloRetryRequest retransmissions. GREASE values
from server responses are rejected as illegal parameters.
Add -grease option to s_client to enable GREASE from the command line.
Closes#9660
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.foundation>
Reviewed-by: Neil Horman <nhorman@openssl.org>
MergeDate: Tue Mar 17 14:58:25 2026
(Merged from https://github.com/openssl/openssl/pull/30303)
The following QUIC transport parameters are now configurable via
SSL_get_value_uint() / SSL_set_value_uint():
max_udp_payload_size
initial_max_data
initial_max_stream_data_{uni, bidi_local, bidi_remote}
initial_max_streams_{uni, bidi}
ack_delay_exponent
max_ack_delay
disable_active_migration
active_connection_id_limit
Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: Saša Nedvědický <sashan@openssl.org>
MergeDate: Tue Mar 17 13:15:29 2026
(Merged from https://github.com/openssl/openssl/pull/29664)
This allows ML_KEM/ML_DSA keys to set a "properties" value
that is used to refetch the digests.
This may be used when doing an import using EVP_PKEY_fromdata().
Note that this is not used by EVP_PKEY_new_raw_private_key_ex() or
EVP_PKEY_new_raw_public_key_ex() since the propq used here is
associated with the keymanager (i.e. via EVP_PKEY_CTX_new_from_name())
not the propq associated with internal fetches used by the key to
fetch digest algorithms.
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
MergeDate: Fri Mar 13 17:24:41 2026
(Merged from https://github.com/openssl/openssl/pull/30243)
This partially reverts commit 07ee3d5db8 "constify
X509_find_by_issuer_and_serial", as it operates on a stack of X509
(not const X509 objects), and returns a pointer to one.
The constification of PKCS7_signatureVerify argument is sensible
(as the argument is read-only inside the function) and is remained
in place.
Fixes: 07ee3d5db8 "constify X509_find_by_issuer_and_serial"
Signed-off-by: Eugene Syromiatnikov <esyr@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Nikola Pajkovsky <nikolap@openssl.org>
Reviewed-by: Neil Horman <nhorman@openssl.org>
MergeDate: Fri Mar 6 21:29:34 2026
(Merged from https://github.com/openssl/openssl/pull/30265)
This reverts constification of the return value types
of X509_STORE_CTX_get_current_cert(), X509_STORE_CTX_get0_current_issuer(),
X509_STORE_CTX_get0_cert() functions, and arguments
of X509_STORE_CTX_set_cert() and X509_STORE_CTX_init() functions.
Constification of users of these functions, as well as
X509_STORE_CTX_get_issuer_fn and X509_STORE_CTX_check_issued_fn types,
remained in place.
Complements: e5b563366b "Constify X509_STORE_CTX functions invoving X509 *"
Signed-off-by: Eugene Syromiatnikov <esyr@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Nikola Pajkovsky <nikolap@openssl.org>
Reviewed-by: Neil Horman <nhorman@openssl.org>
MergeDate: Fri Mar 6 18:33:12 2026
(Merged from https://github.com/openssl/openssl/pull/30272)