If a URXE cannot be processed yet then we add it to the urx_deferred list.
Later, when they can be processed, we requeue them in the urx_pending list.
We must not reverse the order when doing so. We want to process the URXEs
in the order that they were received.
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Todd Short <todd.short@me.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/22452)
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/22405)
Added notes to OPENSSL_INIT_set_config_filename and
OPENSSL_INIT_set_config_appname explaining why strdup
is used instead of OPENSSL_strdup.
CLA: trivial
Co-authored-by: Jean Apolo <jean.apolo@garmin.com>
Signed-off-by: Jean Apolo <jean.apolo@garmin.com>
Signed-off-by: Nate Karstens <nate.karstens@garmin.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21742)
evp_cipher_init_internal() takes a params array argument and this is processed
late in the initialisation process for some ciphers (AEAD ones).
This means that changing the IV length as a parameter will either truncate the
IV (very bad if SP 800-38d section 8.2.1 is used) or grab extra uninitialised
bytes.
Truncation is very bad if SP 800-38d section 8.2.1 is being used to
contruct a deterministic IV. This leads to an instant loss of confidentiality.
Grabbing extra bytes isn't so serious, it will most likely result in a bad
decryption.
Problem reported by Tony Battersby of Cybernetics.com but earlier discovered
and raised as issue #19822.
Fixes CVE-2023-5363
Fixes#19822
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
The 'rand_generate' method is not well suited for being used with
weak entropy sources in the 'get_entropy' callback, because the
caller needs to provide a preallocated buffer without knowing
how much bytes are actually needed to collect the required entropy.
Instead we use the 'rand_get_seed' and 'rand_clear_seed' methods
which were exactly designed for this purpose: it's the callee who
allocates and fills the buffer, and finally cleans it up again.
The 'rand_get_seed' and 'rand_clear_seed' methods are currently
optional for a provided random generator. We could fall back to
using 'rand_generate' if those methods are not implemented.
However, imo it would be better to simply make them an officially
documented requirement for seed sources.
Fixes#22332
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/22394)
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/22394)
Have a new job just to run the fuzz tests with fuzzing build mode enabled.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Hugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/22368)
We allow the fuzzer to influence the time between different packets using
the fake time capability.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Hugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/22368)
We need to call quic_free() to free the record layer to ensure than any
BIO that was already set is also freed.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Hugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/22368)
Some builds that weren't doing fuzzing were defining this which makes no
sense and is not appropriate for non-fuzzing builds.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Hugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/22368)
Add a test for the recently added function OSSL_ERR_STATE_save_to_mark().
We can just modify the existing test_save_restore() to add this in.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Hugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/22368)
When calling qrx_relocate_buffer, both the rxe and the pointer to the token
may be changing locations. We have to use a temporary copy of the token
pointer to avoid referencing the old location of the rxe.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Hugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/22368)
We shouldn't ever have the case where the data flags indicate that
err_data has been malloc'd, but the err_data field is NULL.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Hugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/22368)
We ignore such a bad signature when fuzzing - it will never be correct.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Hugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/22368)
We accept a bad original destination connection id in the transport params
while we are fuzzing since this may change every time.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Hugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/22368)
Handle retryable errors from SSL_read(). Also ensure the underlying BIO
handles the destination address capability.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Hugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/22368)
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/22368)
Earlier today, it took me five manuals! to find what on earth the
"Performance"/"EVP_MD_fetch(3)" crosslinks actually mean:
EVP_sha1(3)
crypto(7)
EVP_MD_fetch(3) (but not there! don't read that!)
OSSL_PROVIDER-default(7)
EVP_MD-SHA1(7)
If, instead, EVP_sha1(3) referenced EVP_MD-SHA1(7) at /all/,
which it should do, since it's supposed to be what you're replacing it
with, but it doesn't actually say that, maybe people would use it.
I know I didn't because it's basically just deadass buried
As found by git grep -l 'and should consider using'
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/22420)
struct timeval doesn't support nanosecs but OSSL_TIME does. We round up
any nanosecs to ensure that a non-zero input always results in a non-zero
output.
This fixes a quic-client fuzzer hang.
Fixes#22437
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/22440)
Creating JDK compatible pkcs12 files requires a bit more than just
adding the Trusted Key Usage OID to a certbag in the pkcs12 file.
Additionally the JDK currently requires that pkcs12 files setting this
oid _not_ contain any additional keys, and in response will produce
unpredictable results.
This could be solved by implying --nokeys when the pkcs12 utility is run
and the config option is set, but thatcould confuse users who didn't
specify nokeys on the command line. As such, remove the config file
setting for this feature, and replace it with a -jdktrust command line
option, that is documented to assert nokeys when a users specifies the
new command line option.
Fixes#22215
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/22422)
Return SSL_SENT_SHUTDOWN and SSL_RECEIVED_SHUTDOWN with semantics
similar to TLS connections.
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/22408)
The one in ch_rx_handle_packet() is a tuning thing -> QUIC FUTURE
The one in ossl_quic_tserver_shutdown() is a server thing -> QUIC SERVER
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/22408)
The `get_user_{entropy,nonce}` callbacks were add recently to the
dispatch table in commit 4cde7585ce. Instead of adding corresponding
`cleanup_user_{entropy,nonce}` callbacks, the `cleanup_{entropy,nonce}`
callbacks were reused. This can cause a problem in the case where the
seed source is replaced by a provider: the buffer gets allocated by
the provider but cleared by the core.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/22423)
RFC 9000 s 17.2.5.2 says
> After the client has received and processed an Initial or Retry packet
> from the server, it MUST discard any subsequent Retry packets that it
> receives.
We were checking for multiple Retry packets, but not if we had already
processed an Initial packet.
Fixes the assertion failure noted in
https://github.com/openssl/openssl/pull/22368#issuecomment-1765618884
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/22411)
This is unnecessary and conceptualy wrong as
headers from internal should not include headers from crypto
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/22432)
