backport of openssl#15924

Reviewed-by: Tomas Mraz <[email protected]>
Reviewed-by: Paul Dale <[email protected]>
(Merged from openssl#15935)

48f1739 did not convert the RSA OAEP
tests correctly. The corrupted ciphertext and truncation tests were
really decrypting uninitialized memory, rather than the sample
ciphertext. This results in an error in tools like MSan.

The test is somewhat roundabout. In the original version, before the
conversion, ctext_ex was an OAEP test vector from key1(), etc.,
functions. The test would:

1. Encrypt ptext_ex as ctext.
2. Decrypt ctext and check it gives ptext_ex.
3. Decrypt ctext_ex and check it gives ptext_ex.
4. Try corrupted and truncated versions of ctext.

48f1739 then moved steps 1 and 2 into
test_rsa_simple, which meant ctext is no longer available for step 4. It
then mistakenly left the variable around, but uninitialized, so the test
wasn't testing anything. (Confusingly, test_rsa_simple outputs ctext_ex
to the caller, but doesn't do anything with it. The ctext_ex output is
also only usable for OAEP, not PKCS#1 v1.5.)

It doesn't really matter whether we use ctext or ctext_ex for step 4, so
this PR fixes it by using ctext_ex instead.

Reviewed-by: Shane Lontis <[email protected]>
Reviewed-by: Paul Dale <[email protected]>
(Merged from openssl#15950)

(cherry picked from commit 36a4637)

Fixes openssl#15958

Reviewed-by: Richard Levitte <[email protected]>
Reviewed-by: Paul Dale <[email protected]>
(Merged from openssl#15973)

There is a problem that appears when calling BN_div(a, c, a, b) with negative b.
In this case, the sign of the remainder c is incorrect.  The problem only
occurs if the dividend and the quotient are the same BIGNUM.

Fixes openssl#15982

Reviewed-by: Nicola Tuveri <[email protected]>
(Merged from openssl#15991)

(cherry picked from commit 105c831)

When creating a signed S/MIME message using SMIME_write_CMS()
if the reading from the bio fails, the state is therefore
still ASN1_STATE_START when BIO_flush() is called by i2d_ASN1_bio_stream().
This results in calling asn1_bio_flush_ex cleanup but will only
reset retry flags as the state is not ASN1_STATE_POST_COPY.
Therefore 48 bytes (Linux x86_64) leaked since the
ndef_prefix_free / ndef_suffix_free callbacks are not executed
and the ndef_aux structure is not freed.

By always calling free function callback in asn1_bio_free() the
memory leak is fixed.

(cherry picked from commit 3a1d2b5)

Reviewed-by: Paul Dale <[email protected]>
Reviewed-by: Tomas Mraz <[email protected]>
(Merged from openssl#15999)

…evel

manual merge from openssl#15818
id d7b5c64

Reviewed-by: Tomas Mraz <[email protected]>
(Merged from openssl#15832)

Manual merge from openssl#15818
Commit id d0e5230

Reviewed-by: Tomas Mraz <[email protected]>
(Merged from openssl#15832)

Issue openssl#15951 describes a scenario which causes s_server to fail when using
a PSK. In the originally described issue this only impacted master and not
1.1.1. However, in fact this issue does also impact 1.1.1 - but only if you
additionally supply the option "-no_ticket" to the s_server command line.

The difference between the behaviour in master and 1.1.1 is due to 9c13b49,
which changed PSK_MAX_IDENTITY_LEN from 128 to 256. It just so happens that
a default OpenSSL TLSv1.3 ticket length happens to fall between those 2
values. Tickets are presented in TLSv1.3 as a PSK "identity". Passing
"no_ticket" doesn't actually stop TLSv1.3 tickets completely, it just
forces the use of "session ids as a ticket" instead. This significantly
reduces the ticket size to below 128 in 1.1.1.

The problem was due to s_server setting a TLSv1.2 PSK callback and a
TLSv1.3 PSK callback. For backwards compat reasons the TLSv1.2 PSK
callbacks also work in TLSv1.3 but are not preferred. In the described
scenario we use a PSK to create the initial connection. Subsequent to that
we attempt a resumption using a TLSv1.3 ticket (psk). If the psk length is
below PSK_MAX_IDENTITY_LEN then we first call the TLSv1.2 PSK callback.
Subsequently we call the TLSv1.3 PSK callback. Unfortunately s_server's
TLSv1.2 PSK callback accepts the identity regardless, even though it is an
unexpected value, and hence the binder subsequently fails to verify.

The fix is to bail early in the TLSv1.2 callback if we detect we are being
called from a TLSv1.3 connection.

Fixes openssl#15951

Reviewed-by: Ben Kaduk <[email protected]>
Reviewed-by: Paul Dale <[email protected]>
(Merged from openssl#16008)

(cherry picked from commit 0007ff2)

…tent

The test case creates an RSA public key and tries to pass it through
i2d_PrivateKey().  This SHOULD fail, since the private bits are missing.

Reviewed-by: Tomas Mraz <[email protected]>
(Merged from openssl#16027)

Fixes openssl#16026

Reviewed-by: Tomas Mraz <[email protected]>
(Merged from openssl#16027)

ASN1_FBOOLEAN is designed to use as a default for optional ASN1 items.
This test program used it for non-optional items, which doesn't encode
well.

Reviewed-by: Tomas Mraz <[email protected]>
(Merged from openssl#16027)

Make it only report (and fail on) encoding/decoding failures when success
is expected.

Reviewed-by: Tomas Mraz <[email protected]>
(Merged from openssl#16027)

Reviewed-by: Tomas Mraz <[email protected]>
(Merged from openssl#16027)

We received a report of an "excessive message size" for a received
session ticket. Our maximum size was significantly less than the theoretical
maximum. The server may put any data it likes in the session ticket
including (for example) the full certificate chain so we should be able to
handle longer tickets. Update the value to the maximum allowed by the spec.

Reviewed-by: Paul Dale <[email protected]>
(Merged from openssl#15877)

(cherry picked from commit e54f0c9)

The flag only affects which record types are queried via DNS (A or
AAAA, or both).  When node is NULL and AF_UNSPEC is used, it prevents
getaddrinfo returning the right address associated with the loopback
interface.

Signed-off-by: Daiki Ueno <[email protected]>

Reviewed-by: Dmitry Belyavskiy <[email protected]>
Reviewed-by: Paul Dale <[email protected]>
(Merged from openssl#16039)

nmake is tolerant of those empty lines, but jom isn't.  That tolerance
isn't standard make behaviour, so we lean towards avoiding them.

We simply use '@Rem' instead.

Fixes openssl#16014

Reviewed-by: Tomas Mraz <[email protected]>
Reviewed-by: Paul Dale <[email protected]>
(Merged from openssl#16047)

This is a follow up of 15729be.  Even
when the host does not support IPv6 at all, BIO_lookup_ex may now
return IN6ADDR_ANY in addition to INADDR_ANY, as the second element of
the ai_next field.

After eee8a40, the do_server function
prefers the IPv6 address and fails on the BIO_socket call.  This adds
a fallback code to retry with the IPv4 address returned as the first
element to avoid the error.

The failure had been partially avoided in the previous code with
AI_ADDRCONFIG, because getaddrinfo returns only IPv4 address if no
IPv6 address is associated with external interface.  However, it would
be still a problem if the external interface has an IPv6 address
assigned, while the loopback interface doesn't.

Signed-off-by: Daiki Ueno <[email protected]>

Reviewed-by: Paul Dale <[email protected]>
Reviewed-by: Tomas Mraz <[email protected]>
(Merged from openssl#16078)

Sometimes this function gets called when the buffers have already been
set up. If there is already a partial packet in the read buffer then the
packet pointer will be set to an incorrect value. The packet pointer already
gets reset to the correct value when we first read a packet anyway, so we
don't also need to do it in ssl3_setup_read_buffer.

Fixes openssl#13729

Reviewed-by: Ben Kaduk <[email protected]>
Reviewed-by: Tomas Mraz <[email protected]>
(Merged from openssl#16098)

If an application is halfway through writing application data it should
not be allowed to attempt an SSL_key_update() operation. Instead the
SSL_write() operation should be completed.

Fixes openssl#12485

Reviewed-by: Ben Kaduk <[email protected]>
Reviewed-by: Tomas Mraz <[email protected]>
(Merged from openssl#16098)

Various comments referred to s->packet and s->packet_length instead of
s->rlayer.packet and s->rlayer.packet_length. Also fixed is a spot where
RECORD_LAYER_write_pending() should have been used. Based on the review
comments in openssl#16077.

Reviewed-by: Tomas Mraz <[email protected]>
Reviewed-by: Ben Kaduk <[email protected]>

(cherry picked from commit ca00152)

Reviewed-by: Paul Dale <[email protected]>
(Merged from openssl#16105)

The ASN1_STRING_get0_data(3) manual explitely cautions the reader
that the data is not necessarily NUL-terminated, and the function
X509_alias_set1(3) does not sanitize the data passed into it in any
way either, so we must assume the return value from X509_alias_get0(3)
is merely a byte array and not necessarily a string in the sense
of the C language.

I found this bug while writing manual pages for X509_print_ex(3)
and related functions.  Theo Buehler <[email protected]> checked my
patch to fix the same bug in LibreSSL, see

http://cvsweb.openbsd.org/src/lib/libcrypto/asn1/t_x509a.c#rev1.9

As an aside, note that the function still produces incomplete and
misleading results when the data contains a NUL byte in the middle
and that error handling is consistently absent throughout, even
though the function provides an "int" return value obviously intended
to be 1 for success and 0 for failure, and even though this function
is called by another function that also wants to return 1 for success
and 0 for failure and even does so in many of its code paths, though
not in others.  But let's stay focussed.  Many things would be nice
to have in the wide wild world, but a buffer overflow must not be
allowed to remain in our backyard.

CLA: trivial

Reviewed-by: Tim Hudson <[email protected]>
Reviewed-by: Paul Dale <[email protected]>
Reviewed-by: Tomas Mraz <[email protected]>
(Merged from openssl#16108)

(cherry picked from commit c5dc9ab)

Fixes openssl#10777

Reviewed-by: Paul Dale <[email protected]>
(Merged from openssl#16130)

(cherry picked from commit 40184c9)

Reviewed-by: Paul Dale <[email protected]>
Reviewed-by: Nicola Tuveri <[email protected]>
Reviewed-by: Dmitry Belyavskiy <[email protected]>
(Merged from openssl#16214)

(cherry picked from commit 3d4ca44)

This reverts commit ea26844.

Reviewed-by: Dmitry Belyavskiy <[email protected]>
(Merged from openssl#16308)

This reverts commit f1d9790.

Reviewed-by: Dmitry Belyavskiy <[email protected]>
(Merged from openssl#16308)

This reverts commit 5434acb.

Reviewed-by: Dmitry Belyavskiy <[email protected]>
(Merged from openssl#16308)

…ing"

This reverts commit 006906c.

Reviewed-by: Dmitry Belyavskiy <[email protected]>
(Merged from openssl#16308)

…h no content"

This reverts commit 12e9b74.

Reviewed-by: Dmitry Belyavskiy <[email protected]>
(Merged from openssl#16308)

The `sk` variable is assigned to `s->session->peer_chain`.
If `ssl3_digest_cached_records()` were to fail, then `sk` would still be
non-NULL, and subsequently freed on the error return. When the session
is freed, it will then attempt to free `s->session->peer_chain`,
resulting in a double-free (of `sk`).

Reviewed-by: Matt Caswell <[email protected]>
Reviewed-by: Tomas Mraz <[email protected]>
(Merged from openssl#16309)

(cherry picked from commit 0449702)

Reviewed-by: Paul Dale <[email protected]>
Reviewed-by: Dmitry Belyavskiy <[email protected]>
Reviewed-by: Tomas Mraz <[email protected]>
(Merged from openssl#17085)

This allows handshake to proceed if the maximum TLS version enabled is <1.3

Fixes openssl#13583

Reviewed-by: Paul Dale <[email protected]>
Reviewed-by: Matt Caswell <[email protected]>
(Merged from openssl#18213)

Reviewed-by: Paul Dale <[email protected]>
Reviewed-by: Matt Caswell <[email protected]>
(Merged from openssl#18213)

rotated_mac is a 64-byte aligned buffer of size 64 and rotate_offset is secret.
Consider a weaker leakage model(CL) where only cacheline base address is leaked,
i.e address/32 for 32-byte cacheline(CL32).

Previous code used to perform two loads
    1. rotated_mac[rotate_offset ^ 32] and
    2. rotated_mac[rotate_offset++]
which would leak 2q + 1, 2q for 0 <= rotate_offset < 32
and 2q, 2q + 1 for 32 <= rotate_offset < 64

The proposed fix performs load operations which will always leak 2q, 2q + 1 and
selects the appropriate value in constant-time.

Reviewed-by: Matt Caswell <[email protected]>
Reviewed-by: Tomas Mraz <[email protected]>
(Merged from openssl#18050)

…to read.

Fixes: openssl#18047.

Reviewed-by: Paul Dale <[email protected]>
Reviewed-by: Tomas Mraz <[email protected]>
(Merged from openssl#18283)

This is a backport of the following commit from master:

commit 415e6ac
Author: Tavis Ormandy <[email protected]>
Date:   Tue Sep 21 15:48:27 2021 -0700

    increase x509 code coverage metrics

    Reviewed-by: Matt Caswell <[email protected]>
    Reviewed-by: Tomas Mraz <[email protected]>
    (Merged from openssl#16651)

Reviewed-by: Matt Caswell <[email protected]>
Reviewed-by: Tomas Mraz <[email protected]>
(Merged from openssl#18347)

This is a backport of the following commit from master:

commit 61b0fea
Author: Matt Caswell <[email protected]>
Date:   Thu Nov 19 13:58:21 2020 +0000

    Don't Overflow when printing Thawte Strong Extranet Version

    When printing human readable info on the Thawte Strong Extranet extension
    the version number could overflow if the version number == LONG_MAX. This
    is undefined behaviour.

    Issue found by OSSFuzz.

    Reviewed-by: Ben Kaduk <[email protected]>
    (Merged from openssl#13452)

Reviewed-by: Matt Caswell <[email protected]>
Reviewed-by: Tomas Mraz <[email protected]>
(Merged from openssl#18347)

This happens usually if an template object is created
and there is an out of memory error before the ASN1_OP_NEW_POST
method is called, but asn1_item_embed_free calls now the
ASN1_OP_FREE_POST which may crash because the object is not
properly initialized.  Apparently that is only an issue with
the ASN1_OP_FREE_POST handling of crypot/x509/x_crl.c, which
ought to be tolerant to incomplete initialized objects.

The error can be reproduced with the reproducible error injection patch:

$ ERROR_INJECT=1652890550 ../util/shlib_wrap.sh ./asn1-test ./corpora/asn1/0ff17293911f54d1538b9896563a4048d67d9ee4
    #0 0x7faae9dbeeba in __sanitizer_print_stack_trace ../../../../gcc-trunk/libsanitizer/asan/asan_stack.cpp:87
    #1 0x408dc4 in my_malloc fuzz/test-corpus.c:114
    #2 0x7faae99f2430 in CRYPTO_zalloc crypto/mem.c:230
    #3 0x7faae97f09e5 in ASN1_STRING_type_new crypto/asn1/asn1_lib.c:341
    #4 0x7faae98118f7 in asn1_primitive_new crypto/asn1/tasn_new.c:318
    #5 0x7faae9812401 in asn1_item_embed_new crypto/asn1/tasn_new.c:78
    #6 0x7faae9812401 in asn1_template_new crypto/asn1/tasn_new.c:240
    #7 0x7faae9812315 in asn1_item_embed_new crypto/asn1/tasn_new.c:137
    #8 0x7faae9812315 in asn1_template_new crypto/asn1/tasn_new.c:240
    #9 0x7faae9812a54 in asn1_item_embed_new crypto/asn1/tasn_new.c:137
    #10 0x7faae9812a54 in ASN1_item_ex_new crypto/asn1/tasn_new.c:39
    #11 0x7faae980be51 in asn1_item_embed_d2i crypto/asn1/tasn_dec.c:325
    #12 0x7faae980c813 in asn1_template_noexp_d2i crypto/asn1/tasn_dec.c:611
    #13 0x7faae980d288 in asn1_template_ex_d2i crypto/asn1/tasn_dec.c:518
    #14 0x7faae980b9ce in asn1_item_embed_d2i crypto/asn1/tasn_dec.c:382
    #15 0x7faae980caf5 in asn1_template_noexp_d2i crypto/asn1/tasn_dec.c:643
    #16 0x7faae980d7d3 in asn1_template_ex_d2i crypto/asn1/tasn_dec.c:494
    #17 0x7faae980b9ce in asn1_item_embed_d2i crypto/asn1/tasn_dec.c:382
    #18 0x7faae980dd1f in ASN1_item_ex_d2i crypto/asn1/tasn_dec.c:124
    #19 0x7faae980de35 in ASN1_item_d2i crypto/asn1/tasn_dec.c:114
    #20 0x40712c in FuzzerTestOneInput fuzz/asn1.c:301
    #21 0x40893b in testfile fuzz/test-corpus.c:182
    #22 0x406b86 in main fuzz/test-corpus.c:226
    #23 0x7faae8eb1f44 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21f44)

AddressSanitizer:DEADLYSIGNAL
=================================================================
==1194==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000010 (pc 0x7faae9b0625f bp 0x7fffffe41a00 sp 0x7fffffe41920 T0)
==1194==The signal is caused by a READ memory access.
==1194==Hint: address points to the zero page.
    #0 0x7faae9b0625f in crl_cb crypto/x509/x_crl.c:258
    #1 0x7faae9811255 in asn1_item_embed_free crypto/asn1/tasn_fre.c:113
    #2 0x7faae9812a65 in asn1_item_embed_new crypto/asn1/tasn_new.c:150
    #3 0x7faae9812a65 in ASN1_item_ex_new crypto/asn1/tasn_new.c:39
    #4 0x7faae980be51 in asn1_item_embed_d2i crypto/asn1/tasn_dec.c:325
    #5 0x7faae980c813 in asn1_template_noexp_d2i crypto/asn1/tasn_dec.c:611
    #6 0x7faae980d288 in asn1_template_ex_d2i crypto/asn1/tasn_dec.c:518
    #7 0x7faae980b9ce in asn1_item_embed_d2i crypto/asn1/tasn_dec.c:382
    #8 0x7faae980caf5 in asn1_template_noexp_d2i crypto/asn1/tasn_dec.c:643
    #9 0x7faae980d7d3 in asn1_template_ex_d2i crypto/asn1/tasn_dec.c:494
    #10 0x7faae980b9ce in asn1_item_embed_d2i crypto/asn1/tasn_dec.c:382
    #11 0x7faae980dd1f in ASN1_item_ex_d2i crypto/asn1/tasn_dec.c:124
    #12 0x7faae980de35 in ASN1_item_d2i crypto/asn1/tasn_dec.c:114
    #13 0x40712c in FuzzerTestOneInput fuzz/asn1.c:301
    #14 0x40893b in testfile fuzz/test-corpus.c:182
    #15 0x406b86 in main fuzz/test-corpus.c:226
    #16 0x7faae8eb1f44 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21f44)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV crypto/x509/x_crl.c:258 in crl_cb
==1194==ABORTING

Reviewed-by: Matt Caswell <[email protected]>
Reviewed-by: Tomas Mraz <[email protected]>
(Merged from openssl#18360)

(cherry picked from commit 557825a)

This is reproducible with my error injection patch:

$ ERROR_INJECT=1652710284 ../util/shlib_wrap.sh ./server-test ./corpora/server/4e48da8aecce6b9b58e8e4dbbf0523e6d2dd56dc
140587884632000:error:03078041:bignum routines:bn_expand_internal:malloc failure:crypto/bn/bn_lib.c:282:
140587884632000:error:10103003:elliptic curve routines:ec_key_simple_oct2priv:BN lib:crypto/ec/ec_key.c:662:
140587884632000:error:100DE08E:elliptic curve routines:old_ec_priv_decode:decode error:crypto/ec/ec_ameth.c:464:
140587884632000:error:0D0680A8:asn1 encoding routines:asn1_check_tlen:wrong tag:crypto/asn1/tasn_dec.c:1149:
140587884632000:error:0D07803A:asn1 encoding routines:asn1_item_embed_d2i:nested asn1 error:crypto/asn1/tasn_dec.c:309:Type=X509_ALGOR
140587884632000:error:0D08303A:asn1 encoding routines:asn1_template_noexp_d2i:nested asn1 error:crypto/asn1/tasn_dec.c:646:Field=pkeyalg, Type=PKCS8_PRIV_KEY_INFO
140587884632000:error:0907B00D:PEM routines:PEM_read_bio_PrivateKey:ASN1 lib:crypto/pem/pem_pkey.c:88:

=================================================================
==19676==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 24 byte(s) in 1 object(s) allocated from:
    #0 0x7fdd2a6bb09f in __interceptor_malloc ../../../../gcc-trunk/libsanitizer/asan/asan_malloc_linux.cpp:69
    #1 0x7fdd2a2fa430 in CRYPTO_zalloc crypto/mem.c:230
    #2 0x7fdd2a15df11 in BN_new crypto/bn/bn_lib.c:246
    #3 0x7fdd2a15df88 in BN_secure_new crypto/bn/bn_lib.c:257
    #4 0x7fdd2a247390 in ec_key_simple_oct2priv crypto/ec/ec_key.c:655
    #5 0x7fdd2a241fc5 in d2i_ECPrivateKey crypto/ec/ec_asn1.c:1030
    #6 0x7fdd2a23dac5 in old_ec_priv_decode crypto/ec/ec_ameth.c:463
    #7 0x7fdd2a109db7 in d2i_PrivateKey crypto/asn1/d2i_pr.c:46
    #8 0x7fdd2a33ab16 in PEM_read_bio_PrivateKey crypto/pem/pem_pkey.c:84
    #9 0x7fdd2a3330b6 in PEM_read_bio_ECPrivateKey crypto/pem/pem_all.c:151
    #10 0x402dba in FuzzerTestOneInput fuzz/server.c:592
    #11 0x40370b in testfile fuzz/test-corpus.c:182
    #12 0x402846 in main fuzz/test-corpus.c:226
    #13 0x7fdd297b9f44 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21f44)

SUMMARY: AddressSanitizer: 24 byte(s) leaked in 1 allocation(s).

Reviewed-by: Tomas Mraz <[email protected]>
Reviewed-by: Matt Caswell <[email protected]>
(Merged from openssl#18361)

This happens for instance with
fuzz/corpora/asn1/65cf44e85614c62f10cf3b7a7184c26293a19e4a
and causes the OPENSSL_malloc below to choke on the
zero length allocation request.

Reviewed-by: Matt Caswell <[email protected]>
Reviewed-by: Tomas Mraz <[email protected]>
(Merged from openssl#18363)

This is reproducible with my error injection patch:

$ ERROR_INJECT=1653267699 ../util/shlib_wrap.sh ./x509-test ./corpora/x509/5f4034ae85d6587dcad4da3e812e80f3d312894d
ERROR_INJECT=1653267699
    #0 0x7fd485a6ad4f in __sanitizer_print_stack_trace ../../../../src/libsanitizer/asan/asan_stack.cc:36
    #1 0x55c12d268724 in my_malloc fuzz/test-corpus.c:114
    #2 0x7fd484f51a75 in CRYPTO_zalloc crypto/mem.c:230
    #3 0x7fd484ed778d in EVP_DigestInit_ex crypto/evp/digest.c:139
    #4 0x7fd4850a9849 in X509_issuer_and_serial_hash crypto/x509/x509_cmp.c:44
    #5 0x55c12d268951 in FuzzerTestOneInput fuzz/x509.c:44
    #6 0x55c12d268239 in testfile fuzz/test-corpus.c:182
    #7 0x55c12d267c7f in main fuzz/test-corpus.c:226
    #8 0x7fd483a42082 in __libc_start_main ../csu/libc-start.c:308
    #9 0x55c12d267e5d in _start (/home/ed/OPCToolboxV5/Source/Core/OpenSSL/openssl/fuzz/x509-test+0x3e5d)

=================================================================
==1058475==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 268 byte(s) in 1 object(s) allocated from:
    #0 0x7fd485a5dc3e in __interceptor_realloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cc:163
    #1 0x7fd484d2eb9b in BUF_MEM_grow crypto/buffer/buffer.c:97
    #2 0x7fd4850b2913 in X509_NAME_oneline crypto/x509/x509_obj.c:43
    #3 0x7fd4850a982f in X509_issuer_and_serial_hash crypto/x509/x509_cmp.c:41
    #4 0x55c12d268951 in FuzzerTestOneInput fuzz/x509.c:44
    #5 0x55c12d268239 in testfile fuzz/test-corpus.c:182
    #6 0x55c12d267c7f in main fuzz/test-corpus.c:226
    #7 0x7fd483a42082 in __libc_start_main ../csu/libc-start.c:308

SUMMARY: AddressSanitizer: 268 byte(s) leaked in 1 allocation(s).

Reviewed-by: Tomas Mraz <[email protected]>
Reviewed-by: Matt Caswell <[email protected]>
(Merged from openssl#18370)

Prior to the crash there is an out of memory error
in X509_verify_cert which makes the chain NULL or
empty.  The error is ignored by ssl_add_cert_chain,
and ssl_security_cert_chain crashes due to the
unchecked null pointer.

This is reproducible with my error injection patch.

The test vector has been validated on the 1.1.1 branch
but the issue is of course identical in all branches.

$ ERROR_INJECT=1652848273 ../util/shlib_wrap.sh ./server-test ./corpora/server/47c8e933c4ec66fa3c309422283dfe0f31aafae8# ./corpora/server/47c8e933c4ec66fa3c309422283dfe0f31aafae8
    #0 0x7f3a8f766eba in __sanitizer_print_stack_trace ../../../../gcc-trunk/libsanitizer/asan/asan_stack.cpp:87
    #1 0x403ba4 in my_malloc fuzz/test-corpus.c:114
    #2 0x7f3a8f39a430 in CRYPTO_zalloc crypto/mem.c:230
    #3 0x7f3a8f46bd3b in sk_reserve crypto/stack/stack.c:180
    #4 0x7f3a8f46bd3b in OPENSSL_sk_insert crypto/stack/stack.c:242
    #5 0x7f3a8f4a4fd8 in sk_X509_push include/openssl/x509.h:99
    #6 0x7f3a8f4a4fd8 in X509_verify_cert crypto/x509/x509_vfy.c:286
    #7 0x7f3a8fed726e in ssl_add_cert_chain ssl/statem/statem_lib.c:959
    #8 0x7f3a8fed726e in ssl3_output_cert_chain ssl/statem/statem_lib.c:1015
    #9 0x7f3a8fee1c50 in tls_construct_server_certificate ssl/statem/statem_srvr.c:3812
    #10 0x7f3a8feb8b0a in write_state_machine ssl/statem/statem.c:843
    #11 0x7f3a8feb8b0a in state_machine ssl/statem/statem.c:443
    #12 0x7f3a8fe84b3f in SSL_do_handshake ssl/ssl_lib.c:3718
    #13 0x403202 in FuzzerTestOneInput fuzz/server.c:740
    #14 0x40371b in testfile fuzz/test-corpus.c:182
    #15 0x402856 in main fuzz/test-corpus.c:226
    #16 0x7f3a8e859f44 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21f44)
    #17 0x402936  (/home/ed/OPC/openssl/fuzz/server-test+0x402936)

AddressSanitizer:DEADLYSIGNAL
=================================================================
==8400==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000158 (pc 0x7f3a8f4d822f bp 0x7ffc39b76190 sp 0x7ffc39b760a0 T0)
==8400==The signal is caused by a READ memory access.
==8400==Hint: address points to the zero page.
    #0 0x7f3a8f4d822f in x509v3_cache_extensions crypto/x509v3/v3_purp.c:386
    #1 0x7f3a8f4d9d3a in X509_check_purpose crypto/x509v3/v3_purp.c:84
    #2 0x7f3a8f4da02a in X509_get_extension_flags crypto/x509v3/v3_purp.c:921
    #3 0x7f3a8feff7d2 in ssl_security_cert_sig ssl/t1_lib.c:2518
    #4 0x7f3a8feff7d2 in ssl_security_cert ssl/t1_lib.c:2542
    #5 0x7f3a8feffa03 in ssl_security_cert_chain ssl/t1_lib.c:2562
    #6 0x7f3a8fed728d in ssl_add_cert_chain ssl/statem/statem_lib.c:963
    #7 0x7f3a8fed728d in ssl3_output_cert_chain ssl/statem/statem_lib.c:1015
    #8 0x7f3a8fee1c50 in tls_construct_server_certificate ssl/statem/statem_srvr.c:3812
    #9 0x7f3a8feb8b0a in write_state_machine ssl/statem/statem.c:843
    #10 0x7f3a8feb8b0a in state_machine ssl/statem/statem.c:443
    #11 0x7f3a8fe84b3f in SSL_do_handshake ssl/ssl_lib.c:3718
    #12 0x403202 in FuzzerTestOneInput fuzz/server.c:740
    #13 0x40371b in testfile fuzz/test-corpus.c:182
    #14 0x402856 in main fuzz/test-corpus.c:226
    #15 0x7f3a8e859f44 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21f44)
    #16 0x402936  (/home/ed/OPC/openssl/fuzz/server-test+0x402936)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV crypto/x509v3/v3_purp.c:386 in x509v3_cache_extensions
==8400==ABORTING

Reviewed-by: Tomas Mraz <[email protected]>
Reviewed-by: Matt Caswell <[email protected]>
(Merged from openssl#18376)

(cherry picked from commit dc0ef29)

This can be reproduced with my error injection patch.

The test vector has been validated on the 1.1.1 branch
but the issue is of course identical in all branches.

$ ERROR_INJECT=1653520461 ../util/shlib_wrap.sh ./cms-test ./corpora/cms/3eff1d2f1232bd66d5635db2c3f9e7f23830dfd1
log file: cms-3eff1d2f1232bd66d5635db2c3f9e7f23830dfd1-32454-test.out
ERROR_INJECT=1653520461
    #0 0x7fd5d8b8eeba in __sanitizer_print_stack_trace ../../../../gcc-trunk/libsanitizer/asan/asan_stack.cpp:87
    #1 0x402fc4 in my_realloc fuzz/test-corpus.c:129
    #2 0x7fd5d8893c49 in sk_reserve crypto/stack/stack.c:198
    #3 0x7fd5d8893c49 in OPENSSL_sk_insert crypto/stack/stack.c:242
    #4 0x7fd5d88d6d7f in sk_GENERAL_NAMES_push include/openssl/x509v3.h:168
    #5 0x7fd5d88d6d7f in crl_set_issuers crypto/x509/x_crl.c:111
    #6 0x7fd5d88d6d7f in crl_cb crypto/x509/x_crl.c:246
    #7 0x7fd5d85dc032 in asn1_item_embed_d2i crypto/asn1/tasn_dec.c:432
    #8 0x7fd5d85dcaf5 in asn1_template_noexp_d2i crypto/asn1/tasn_dec.c:643
    #9 0x7fd5d85dd288 in asn1_template_ex_d2i crypto/asn1/tasn_dec.c:518
    #10 0x7fd5d85db2b5 in asn1_item_embed_d2i crypto/asn1/tasn_dec.c:259
    #11 0x7fd5d85dc813 in asn1_template_noexp_d2i crypto/asn1/tasn_dec.c:611
    #12 0x7fd5d85dd288 in asn1_template_ex_d2i crypto/asn1/tasn_dec.c:518
    #13 0x7fd5d85db9ce in asn1_item_embed_d2i crypto/asn1/tasn_dec.c:382
    #14 0x7fd5d85dca28 in asn1_template_noexp_d2i crypto/asn1/tasn_dec.c:633
    #15 0x7fd5d85dd288 in asn1_template_ex_d2i crypto/asn1/tasn_dec.c:518
    #16 0x7fd5d85db9ce in asn1_item_embed_d2i crypto/asn1/tasn_dec.c:382
    #17 0x7fd5d85dcaf5 in asn1_template_noexp_d2i crypto/asn1/tasn_dec.c:643
    #18 0x7fd5d85dd7d3 in asn1_template_ex_d2i crypto/asn1/tasn_dec.c:494
    #19 0x7fd5d85db9ce in asn1_item_embed_d2i crypto/asn1/tasn_dec.c:382
    #20 0x7fd5d85ddd1f in ASN1_item_ex_d2i crypto/asn1/tasn_dec.c:124
    #21 0x7fd5d85dde35 in ASN1_item_d2i crypto/asn1/tasn_dec.c:114
    #22 0x7fd5d85a77e0 in ASN1_item_d2i_bio crypto/asn1/a_d2i_fp.c:69
    #23 0x402845 in FuzzerTestOneInput fuzz/cms.c:43
    #24 0x402bbb in testfile fuzz/test-corpus.c:182
    #25 0x402626 in main fuzz/test-corpus.c:226
    #26 0x7fd5d7c81f44 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21f44)
    #27 0x402706  (/home/ed/OPC/openssl/fuzz/cms-test+0x402706)

=================================================================
==29625==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 32 byte(s) in 1 object(s) allocated from:
    #0 0x7fd5d8b8309f in __interceptor_malloc ../../../../gcc-trunk/libsanitizer/asan/asan_malloc_linux.cpp:69
    #1 0x7fd5d87c2430 in CRYPTO_zalloc crypto/mem.c:230
    #2 0x7fd5d889501f in OPENSSL_sk_new_reserve crypto/stack/stack.c:209
    #3 0x7fd5d85dcbc3 in sk_ASN1_VALUE_new_null include/openssl/asn1t.h:928
    #4 0x7fd5d85dcbc3 in asn1_template_noexp_d2i crypto/asn1/tasn_dec.c:577
    #5 0x7fd5d85dd288 in asn1_template_ex_d2i crypto/asn1/tasn_dec.c:518
    #6 0x7fd5d85db104 in asn1_item_embed_d2i crypto/asn1/tasn_dec.c:178
    #7 0x7fd5d85ddd1f in ASN1_item_ex_d2i crypto/asn1/tasn_dec.c:124
    #8 0x7fd5d85dde35 in ASN1_item_d2i crypto/asn1/tasn_dec.c:114
    #9 0x7fd5d88f86d9 in X509V3_EXT_d2i crypto/x509v3/v3_lib.c:142
    #10 0x7fd5d88d6d3c in crl_set_issuers crypto/x509/x_crl.c:97
    #11 0x7fd5d88d6d3c in crl_cb crypto/x509/x_crl.c:246
    #12 0x7fd5d85dc032 in asn1_item_embed_d2i crypto/asn1/tasn_dec.c:432
    #13 0x7fd5d85dcaf5 in asn1_template_noexp_d2i crypto/asn1/tasn_dec.c:643
    #14 0x7fd5d85dd288 in asn1_template_ex_d2i crypto/asn1/tasn_dec.c:518
    #15 0x7fd5d85db2b5 in asn1_item_embed_d2i crypto/asn1/tasn_dec.c:259
    #16 0x7fd5d85dc813 in asn1_template_noexp_d2i crypto/asn1/tasn_dec.c:611
    #17 0x7fd5d85dd288 in asn1_template_ex_d2i crypto/asn1/tasn_dec.c:518
    #18 0x7fd5d85db9ce in asn1_item_embed_d2i crypto/asn1/tasn_dec.c:382
    #19 0x7fd5d85dca28 in asn1_template_noexp_d2i crypto/asn1/tasn_dec.c:633
    #20 0x7fd5d85dd288 in asn1_template_ex_d2i crypto/asn1/tasn_dec.c:518
    #21 0x7fd5d85db9ce in asn1_item_embed_d2i crypto/asn1/tasn_dec.c:382
    #22 0x7fd5d85dcaf5 in asn1_template_noexp_d2i crypto/asn1/tasn_dec.c:643
    #23 0x7fd5d85dd7d3 in asn1_template_ex_d2i crypto/asn1/tasn_dec.c:494
    #24 0x7fd5d85db9ce in asn1_item_embed_d2i crypto/asn1/tasn_dec.c:382
    #25 0x7fd5d85ddd1f in ASN1_item_ex_d2i crypto/asn1/tasn_dec.c:124
    #26 0x7fd5d85dde35 in ASN1_item_d2i crypto/asn1/tasn_dec.c:114
    #27 0x7fd5d85a77e0 in ASN1_item_d2i_bio crypto/asn1/a_d2i_fp.c:69
    #28 0x402845 in FuzzerTestOneInput fuzz/cms.c:43
    #29 0x402bbb in testfile fuzz/test-corpus.c:182
    #30 0x402626 in main fuzz/test-corpus.c:226
    #31 0x7fd5d7c81f44 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21f44)

SUMMARY: AddressSanitizer: 32 byte(s) leaked in 1 allocation(s).

Reviewed-by: Paul Dale <[email protected]>
Reviewed-by: Tomas Mraz <[email protected]>
(Merged from openssl#18391)

(cherry picked from commit e9007e0)

Reviewed-by: Matt Caswell <[email protected]>
Reviewed-by: Dmitry Belyavskiy <[email protected]>
(Merged from openssl#18446)

Reviewed-by: Matt Caswell <[email protected]>
Reviewed-by: Dmitry Belyavskiy <[email protected]>
(Merged from openssl#18446)

When TLS-1.3 is used and the server does not send any CA names
the ca_dn will be NULL. sk_X509_NAME_num() returns -1 on null
argument.

Reviewed-by: Todd Short <[email protected]>
Reviewed-by: Matt Caswell <[email protected]>
(Merged from openssl#17986)

(cherry picked from commit 89dd854)

Namely the smime certificates used in test_cms
will expire soon and affect tests.

Fixes openssl#15179

Reviewed-by: Dmitry Belyavskiy <[email protected]>
Reviewed-by: Paul Dale <[email protected]>
(Merged from openssl#18481)

If the asnum or rdi fields are NULL and the ASIdentifiers are otherwise
subsets then this will result in a crash. Of note is that rdi will usually
be NULL.

Reported by Theo Buehler (@botovq)

Reviewed-by: Tomas Mraz <[email protected]>
Reviewed-by: Paul Yang <[email protected]>
Reviewed-by: Todd Short <[email protected]>
(Merged from openssl#18514)

(cherry picked from commit 01fc9b6)

This partially fixes a bug where, on x86_64, BN_mod_exp_mont_consttime
would sometimes return m, the modulus, when it should have returned
zero. Thanks to Guido Vranken for reporting it. It is only a partial fix
because the same bug also exists in the "rsaz" codepath.

The bug only affects zero outputs (with non-zero inputs), so we believe
it has no security impact on our cryptographic functions.

The fx is to delete lowercase bn_from_montgomery altogether, and have the
mont5 path use the same BN_from_montgomery ending as the non-mont5 path.
This only impacts the final step of the whole exponentiation and has no
measurable perf impact.

See the original BoringSSL commit
https://boringssl.googlesource.com/boringssl/+/13c9d5c69d04485a7a8840c12185c832026c8315
for further analysis.

Original-author: David Benjamin <[email protected]>

Reviewed-by: Matt Caswell <[email protected]>
Reviewed-by: Paul Dale <[email protected]>
(Merged from openssl#18511)

Inspired by BoringSSL fix by David Benjamin.

Reviewed-by: Matt Caswell <[email protected]>
Reviewed-by: Paul Dale <[email protected]>
(Merged from openssl#18511)

Commit 8bfb750 updated
`BIO_f_base64(3)` to improve the documentation of the
`BIO_FLAGS_BASE64_NO_NL` flag.  In particular, the updated text
states that when this flag is used, all newlines in the input are
ignored.  This is incorrect, as the following program proves:

```c

unsigned char *in_buf =
    "IlRoZSBxdWljayBicm93biBmb3gganVt\ncHMgb3ZlciBhIGxhenkgZG9nLiI=\n";

int main(int argc, char **argv) {
    BIO *b64 = BIO_new(BIO_f_base64());
    if (b64 == NULL) return 1;
    BIO_set_flags(b64, BIO_get_flags(b64) | BIO_FLAGS_BASE64_NO_NL);
    int in_len = strlen(in_buf);
    BIO *in = BIO_new_mem_buf(in_buf, in_len);
    if (in == NULL) return 2;
    in = BIO_push(b64, in);
    unsigned char *out_buf = calloc(in_len, sizeof(unsigned char));
    if (out_buf == NULL) return 3;
    size_t out_len;
    int r = BIO_read_ex(in, out_buf, in_len, &out_len);
    printf("rv = %d\n", r);
    printf("decoded = %s\n", out_buf);
    return 0;
}
```

Update the text of `BIO_f_base64(3)` to clarify that when the flag
is set, the data must be all on one line (with or without a trailing
newline character).

Signed-off-by: Fraser Tweedale <[email protected]>

Reviewed-by: Paul Dale <[email protected]>
Reviewed-by: Tomas Mraz <[email protected]>
(Merged from openssl#18568)

(cherry picked from commit 0edcbac)

CVE-2022-2068

Reviewed-by: Matt Caswell <[email protected]>
Reviewed-by: Richard Levitte <[email protected]>

Reviewed-by: Tomas Mraz <[email protected]>
Release: yes

Reviewed-by: Richard Levitte <[email protected]>
Release: yes

Reviewed-by: Richard Levitte <[email protected]>
Release: yes