This reverts commit 2b74e75331.
The commit was wrong. With 3.x versions the engines must be themselves
responsible for creating their EVP_PKEYs in a way that they are treated
as legacy - either by using the respective set1 calls or by setting
non-default EVP_PKEY_METHOD.
The workaround has caused more problems than it solved.
Fixes#22945
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
Reviewed-by: Neil Horman <nhorman@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/23063)
In writing the quic stateless reset test we found that the quic rx code
wasn't checking for stateless reest conditions, as the SRT frames were
getting discarded due to failed lcdim lookups. Move the SRT check above
the lcdim lookup in the rx path to ensure we handle SRT properly in the
client.
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/23384)
QUIC supports the concept of stateless reset, in which a specially
crafted frame is sent to a client informing it that the QUIC state
information is no longer available, and the connection should be closed
immediately. Test for proper client support here
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/23384)
For some reason, those functions (and the _init functions too) would
raise EVP_R_OPERATION_NOT_SUPPORTED_FOR_THIS_KEYTYPE when the passed
ctx is NULL, and then not check if the provider supplied the function
that would support these libcrypto functions.
This corrects the situation, and has all those libcrypto functions
raise ERR_R_PASS_NULL_PARAMETER if ctx is NULL, and then check for the
corresponding provider supplied, and only when that one is missing,
raise EVP_R_OPERATION_NOT_SUPPORTED_FOR_THIS_KEYTYPE.
Because 0 doesn't mean error for EVP_PKEY_verify(), -1 is returned when
ERR_R_PASSED_NULL_PARAMETER is raised. This is done consistently for all
affected functions.
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/23411)
bind_afalg calls afalg_aes_cbc which allocates
cipher_handle->_hidden global object(s)
but if one of them fails due to out of memory,
the function bind_afalg relies on the engine destroy
method to be called. But that does not happen
because the dynamic engine object is not destroyed
in the usual way in dynamic_load in this case:
If the bind_engine function fails, there will be no
further calls into the shared object.
See ./crypto/engine/eng_dyn.c near the comment:
/* Copy the original ENGINE structure back */
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/23409)
No need to create and copy BIGNUM p, a and b, just call
EC_GROUP_get0_field() instead.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Yang <kaishen.yy@antfin.com>
(Merged from https://github.com/openssl/openssl/pull/23313)
The parameter list for CRYPTO_DOWN_REF for the icc on windows build was
incorrect.
This issue was introduced by 99fd5b2b10Fixes#23414
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Hugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/23415)
SSL_clear() explicitly clears an SSL object to enable it to be reused.
You can have a similar effect by calling SSL_set_accept_state() or
SSL_set_connect_state(). We extend the testing of SSL_clear() to use these
other methods. We also ensure we test the case where we have unread
bufferred data that needs to be cleared.
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/23256)
Freeing the QUIC TLS object may make calls back into QUIC so we should
free it first.
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/23256)
The TLS object may make callbacks into QUIC during cleanup so we must
free it first.
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/23256)
We had two functions which were very similarly named, that did almost the
same thing, but not quite. We bring the two together. Doing this also fixes
a possible bug where some data may not be correctly freed when the
RECORD_LAYER_clear() version was used.
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/23256)
Using the client one when the server once should be used could cause a
later call to SSL_set_accept_state() to unexpectedly fail.
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/23256)
When we clear the record layer, we better make sure we clear all relevant
fields, otherwise we can get ourselves into an unexpected state.
Fixes#23255
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/23256)
Coverity issue 1453632 noted a missing null check in kdf_test_ctrl
recently. If a malformed value is passed in from the test file that
does not contain a ':' character, the p variable will be NULL, leading
to a NULL derefence prepare_from_text
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
(Merged from https://github.com/openssl/openssl/pull/23398)
strstr() is used to match multiple characters in the haystack,
whereas strchr() is used to matched only single character.
CLA: trivial
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/23347)
The failure would be caught later on, so this went unnoticed, until someone
tried with just one hex digit, which was simply ignored.
Fixes#23373
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/23374)
PKCS7 ContentInfo fields held within a PKCS12 file can be NULL, even if the
type has been set to a valid value. CVE-2024-0727 is a result of OpenSSL
attempting to dereference the NULL pointer as a result of this.
We add test for various instances of this problem.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Neil Horman <nhorman@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/23361)
PKCS12 structures contain PKCS7 ContentInfo fields. These fields are
optional and can be NULL even if the "type" is a valid value. OpenSSL
was not properly accounting for this and a NULL dereference can occur
causing a crash.
CVE-2024-0727
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Neil Horman <nhorman@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/23361)
make sure that we get the expected error codes when we do bad things,
rather than a crash
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/22995)
The EVP_CIPHER api currently assumes that calls made into several APIs
have already initalized the cipher in a given context via a call to
EVP_CipherInit[_ex[2]]. If that hasnt been done, instead of an error,
the result is typically a SIGSEGV.
Correct that by adding missing NULL checks in the apropriate apis prior
to using ctx->cipher
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/22995)
if the private key is output to stdout using the HARNESS_OSSL_PREFIX,
out is a stack of BIOs and must therefore free'd using BIO_free_all.
Steps to reproduce:
$ HARNESS_OSSL_PREFIX=x OPENSSL_CONF=apps/openssl.cnf util/shlib_wrap.sh apps/openssl req -new -keyout - -passout pass: </dev/null
[...]
Direct leak of 128 byte(s) in 1 object(s) allocated from:
#0 0x7f6f692b89cf in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:69
#1 0x7f6f686eda00 in CRYPTO_malloc crypto/mem.c:202
#2 0x7f6f686edba0 in CRYPTO_zalloc crypto/mem.c:222
#3 0x7f6f68471bdf in BIO_new_ex crypto/bio/bio_lib.c:83
#4 0x7f6f68491a8f in BIO_new_fp crypto/bio/bss_file.c:95
#5 0x555c5f58b378 in dup_bio_out apps/lib/apps.c:3014
#6 0x555c5f58f9ac in bio_open_default_ apps/lib/apps.c:3175
#7 0x555c5f58f9ac in bio_open_default apps/lib/apps.c:3203
#8 0x555c5f528537 in req_main apps/req.c:683
#9 0x555c5f50e315 in do_cmd apps/openssl.c:426
#10 0x555c5f4c5575 in main apps/openssl.c:307
#11 0x7f6f680461c9 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
SUMMARY: AddressSanitizer: 128 byte(s) leaked in 1 allocation(s).
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/23365)
actions-rs/toolchain is unmaintained and generates warnings
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: Hugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/23232)
CLA: trivial
Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: Hugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/23345)
* iOS 6 and 7 got its last updates 2014.
* Adding -mios-simulator-version-min=14.0 to the configure command leads to two occurences of this parameter during compilation.
* So lets remove this values to allow a robust configuration from outside and avoid updates here in the future.
CLA: trivial
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/23344)
Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/23307)
array"key" is uninitialized and it is being read directly in function SipHash_Init() as per the below statements making a way for the garbage values :
uint64_t k0 = U8TO64_LE(k);
uint64_t k1 = U8TO64_LE(k + 8);
CLA: trivial
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/23298)
this could be triggered by the following code (assuming 64 bit time_t):
time_t t = 67768011791126057ULL;
ASN1_TIME* at = ASN1_TIME_set(NULL, t);
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/22976)
this needs a sanitized 64 bit time_t build to be detected (or possibly
valgrind, trapv or similar)
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/22976)
Don't check the Max Fragment Length if the it hasn't been negotiated. We
were checking it anyway, and using the default value
(SSL3_RT_MAX_PLAIN_LENGTH). This works in most cases but KTLS can cause the
record length to actually exceed this in some cases.
Fixes#23169
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Neil Horman <nhorman@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/23182)
Check that we can write and read back long app data records when using
KTLS.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Neil Horman <nhorman@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/23182)
Also document that it is ok to use this for control flow decisions.
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/23304)
The function in question is SSL_get_peer_certificate()
CLA: trivial
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/23315)
ubsan on clang17 has started warning about the following undefined
behavior:
crypto/lhash/lhash.c:299:12: runtime error: call to function err_string_data_hash through pointer to incorrect function type 'unsigned long (*)(const void *)'
[...]/crypto/err/err.c:184: note: err_string_data_hash defined here
#0 0x7fa569e3a434 in getrn [...]/crypto/lhash/lhash.c:299:12
#1 0x7fa569e39a46 in OPENSSL_LH_insert [...]/crypto/lhash/lhash.c:119:10
#2 0x7fa569d866ee in err_load_strings [...]/crypto/err/err.c:280:15
[...]
The issue occurs because, the generic hash functions (OPENSSL_LH_*) will
occasionaly call back to the type specific registered functions for hash
generation/comparison/free/etc, using functions of the (example)
prototype:
[return value] <hash|cmp|free> (void *, [void *], ...)
While the functions implementing hash|cmp|free|etc are defined as
[return value] <fnname> (TYPE *, [TYPE *], ...)
The compiler, not knowing the type signature of the function pointed to
by the implementation, performs no type conversion on the function
arguments
While the C language specification allows for pointers to data of one
type to be converted to pointers of another type, it does not
allow for pointers to functions with one signature to be called
while pointing to functions of another signature. Compilers often allow
this behavior, but strictly speaking it results in undefined behavior
As such, ubsan warns us about this issue
This is an potential fix for the issue, implemented using, in effect,
thunking macros. For each hash type, an additional set of wrapper
funtions is created (currently for compare and hash, but more will be
added for free/doall/etc). The corresponding thunking macros for each
type cases the actuall corresponding callback to a function pointer of
the proper type, and then calls that with the parameters appropriately
cast, avoiding the ubsan warning
This approach is adventageous as it maintains a level of type safety,
but comes at the cost of having to implement several additional
functions per hash table type.
Related to #22896
Reviewed-by: Sasa Nedvedicky <sashan@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/23192)
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: David von Oheimb <david.von.oheimb@siemens.com>
(Merged from https://github.com/openssl/openssl/pull/19948)
