upstream 111q merge #377
Merged
upstream 111q merge #377
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Reviewed-by: Tomas Mraz <tomas@openssl.org> (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 <pauli@openssl.org> (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 <dueno@redhat.com> Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com> Reviewed-by: Paul Dale <pauli@openssl.org> (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 <tomas@openssl.org> Reviewed-by: Paul Dale <pauli@openssl.org> (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 <dueno@redhat.com> Reviewed-by: Paul Dale <pauli@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (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 <kaduk@mit.edu> Reviewed-by: Tomas Mraz <tomas@openssl.org> (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 <kaduk@mit.edu> Reviewed-by: Tomas Mraz <tomas@openssl.org> (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 <tomas@openssl.org> Reviewed-by: Ben Kaduk <kaduk@mit.edu> (cherry picked from commit ca00152) Reviewed-by: Paul Dale <pauli@openssl.org> (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 <tb@openbsd.org> 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 <tjh@openssl.org> Reviewed-by: Paul Dale <pauli@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from openssl#16108) (cherry picked from commit c5dc9ab)
Fixes openssl#10777 Reviewed-by: Paul Dale <pauli@openssl.org> (Merged from openssl#16130) (cherry picked from commit 40184c9)
Reviewed-by: Paul Dale <pauli@openssl.org> Reviewed-by: Nicola Tuveri <nic.tuv@gmail.com> Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com> (Merged from openssl#16214) (cherry picked from commit 3d4ca44)
This reverts commit ea26844. Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com> (Merged from openssl#16308)
This reverts commit f1d9790. Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com> (Merged from openssl#16308)
This reverts commit 5434acb. Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com> (Merged from openssl#16308)
…ing" This reverts commit 006906c. Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com> (Merged from openssl#16308)
…h no content" This reverts commit 12e9b74. Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com> (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 <matt@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from openssl#16309) (cherry picked from commit 0449702)
Copy the current IV from the cipher context into the kmo/kmf param before the operation, and copy the modified IV back to the context afterwards. Without this, an application that obtains the running IV from the context would still get the original IV, but not the updated one. Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com> Reviewed-by: Patrick Steuer <patrick.steuer@de.ibm.com> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from openssl#16292)
Ensure that an EVP_CipherUpdate operation updates the context's IV for AES CBC, CFB, OFB, and CTR. An application can get the updated IV via EVP_CIPHER_CTX_iv(). The s390x implementation of the CFB and OFB ciphers did not update the IV in the context, but only within its s390x specific context data. Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com> Reviewed-by: Patrick Steuer <patrick.steuer@de.ibm.com> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from openssl#16292)
Fixes openssl#16331 Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com> Reviewed-by: Kurt Roeckx <kurt@roeckx.be> (Merged from openssl#16333)
Reviewed-by: Paul Dale <pauli@openssl.org> (Merged from openssl#16252)
Reviewed-by: Paul Dale <pauli@openssl.org> (Merged from openssl#16252)
Reviewed-by: Paul Dale <pauli@openssl.org> (Merged from openssl#16252)
This commit does not include the daily run-checker workflow. Reviewed-by: Paul Dale <pauli@openssl.org> (Merged from openssl#16252)
The daily run-checker is scheduled to start at 6:42, instead of the start of the hour. The official GitHub documentation remarks the following regarding scheduled workflows: > Note: The schedule event can be delayed during periods of high loads > of GitHub Actions workflow runs. High load times include the start of > every hour. To decrease the chance of delay, schedule your workflow to > run at a different time of the hour. 42, obviously, has been picked because it is the answer to the ultimate question of life, the universe, and everything. Reviewed-by: Paul Dale <pauli@openssl.org> (Merged from openssl#16252)
This commit temporarily disables cross-compiling tests for sparcv9, due to failures to be investigated in a dedicated PR. Reviewed-by: Paul Dale <pauli@openssl.org> (Merged from openssl#16252)
This commit temporarily disables krb5 external tests, due to failures to be investigated in a dedicated PR. Reviewed-by: Paul Dale <pauli@openssl.org> (Merged from openssl#16252)
This commit temporarily disables pyca external tests, due to failures to be investigated in a dedicated PR. Reviewed-by: Paul Dale <pauli@openssl.org> (Merged from openssl#16252)
This commit temporarily disables tests for no-tls1_3, due to failures to be investigated in a dedicated PR. Reviewed-by: Paul Dale <pauli@openssl.org> (Merged from openssl#16252)
In 1.1.1 currently we do not support running multiple tests in parallel, and the `--debug -O1` msan build required more than 3h to run the tests. This commit temporarily disables this build configuration. Reviewed-by: Paul Dale <pauli@openssl.org> (Merged from openssl#16252)
Namely the smime certificates used in test_cms will expire soon and affect tests. Fixes openssl#15179 Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com> Reviewed-by: Paul Dale <pauli@openssl.org> (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 <tomas@openssl.org> Reviewed-by: Paul Yang <kaishen.yy@antfin.com> Reviewed-by: Todd Short <todd.short@me.com> (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 <davidben@google.com> Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Paul Dale <pauli@openssl.org> (Merged from openssl#18511)
Inspired by BoringSSL fix by David Benjamin. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Paul Dale <pauli@openssl.org> (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 <ftweedal@redhat.com> Reviewed-by: Paul Dale <pauli@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from openssl#18568) (cherry picked from commit 0edcbac)
CVE-2022-2068 Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org> Release: yes
Reviewed-by: Richard Levitte <levitte@openssl.org> Release: yes
Reviewed-by: Richard Levitte <levitte@openssl.org> Release: yes
Reviewed-by: Richard Levitte <levitte@openssl.org> Release: yes
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=1656112173 ../util/shlib_wrap.sh ./x509-test ./corpora/x509/fe543a8d7e09109a9a08114323eefec802ad79e2
#0 0x7fb61945eeba in __sanitizer_print_stack_trace ../../../../gcc-trunk/libsanitizer/asan/asan_stack.cpp:87
#1 0x402f84 in my_malloc fuzz/test-corpus.c:114
#2 0x7fb619092430 in CRYPTO_zalloc crypto/mem.c:230
#3 0x7fb618ef7561 in bn_expand_internal crypto/bn/bn_lib.c:280
#4 0x7fb618ef7561 in bn_expand2 crypto/bn/bn_lib.c:304
#5 0x7fb618ef819d in BN_bin2bn crypto/bn/bn_lib.c:454
#6 0x7fb618e7aa13 in asn1_string_to_bn crypto/asn1/a_int.c:503
#7 0x7fb618e7aa13 in ASN1_INTEGER_to_BN crypto/asn1/a_int.c:559
#8 0x7fb618fd8e79 in EC_GROUP_new_from_ecparameters crypto/ec/ec_asn1.c:814
#9 0x7fb618fd98e8 in EC_GROUP_new_from_ecpkparameters crypto/ec/ec_asn1.c:935
#10 0x7fb618fd9aec in d2i_ECPKParameters crypto/ec/ec_asn1.c:966
#11 0x7fb618fdace9 in d2i_ECParameters crypto/ec/ec_asn1.c:1184
#12 0x7fb618fd1fc7 in eckey_type2param crypto/ec/ec_ameth.c:119
#13 0x7fb618fd57b4 in eckey_pub_decode crypto/ec/ec_ameth.c:165
#14 0x7fb6191a9c62 in x509_pubkey_decode crypto/x509/x_pubkey.c:124
#15 0x7fb6191a9e42 in pubkey_cb crypto/x509/x_pubkey.c:46
#16 0x7fb618eac032 in asn1_item_embed_d2i crypto/asn1/tasn_dec.c:432
#17 0x7fb618eacaf5 in asn1_template_noexp_d2i crypto/asn1/tasn_dec.c:643
#18 0x7fb618ead288 in asn1_template_ex_d2i crypto/asn1/tasn_dec.c:518
#19 0x7fb618eab9ce in asn1_item_embed_d2i crypto/asn1/tasn_dec.c:382
#20 0x7fb618eacaf5 in asn1_template_noexp_d2i crypto/asn1/tasn_dec.c:643
#21 0x7fb618ead288 in asn1_template_ex_d2i crypto/asn1/tasn_dec.c:518
#22 0x7fb618eab9ce in asn1_item_embed_d2i crypto/asn1/tasn_dec.c:382
#23 0x7fb618eadd1f in ASN1_item_ex_d2i crypto/asn1/tasn_dec.c:124
#24 0x7fb618eade35 in ASN1_item_d2i crypto/asn1/tasn_dec.c:114
#25 0x40310c in FuzzerTestOneInput fuzz/x509.c:33
#26 0x402afb in testfile fuzz/test-corpus.c:182
#27 0x402656 in main fuzz/test-corpus.c:226
#28 0x7fb618551f44 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21f44)
#29 0x402756 (/home/ed/OPC/openssl/fuzz/x509-test+0x402756)
=================================================================
==12221==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 24 byte(s) in 1 object(s) allocated from:
#0 0x7fb61945309f in __interceptor_malloc ../../../../gcc-trunk/libsanitizer/asan/asan_malloc_linux.cpp:69
#1 0x7fb619092430 in CRYPTO_zalloc crypto/mem.c:230
#2 0x7fb618ef5f11 in BN_new crypto/bn/bn_lib.c:246
#3 0x7fb618ef82f4 in BN_bin2bn crypto/bn/bn_lib.c:440
#4 0x7fb618fd8933 in EC_GROUP_new_from_ecparameters crypto/ec/ec_asn1.c:618
#5 0x7fb618fd98e8 in EC_GROUP_new_from_ecpkparameters crypto/ec/ec_asn1.c:935
#6 0x7fb618fd9aec in d2i_ECPKParameters crypto/ec/ec_asn1.c:966
#7 0x7fb618fdace9 in d2i_ECParameters crypto/ec/ec_asn1.c:1184
#8 0x7fb618fd1fc7 in eckey_type2param crypto/ec/ec_ameth.c:119
#9 0x7fb618fd57b4 in eckey_pub_decode crypto/ec/ec_ameth.c:165
#10 0x7fb6191a9c62 in x509_pubkey_decode crypto/x509/x_pubkey.c:124
#11 0x7fb6191a9e42 in pubkey_cb crypto/x509/x_pubkey.c:46
#12 0x7fb618eac032 in asn1_item_embed_d2i crypto/asn1/tasn_dec.c:432
#13 0x7fb618eacaf5 in asn1_template_noexp_d2i crypto/asn1/tasn_dec.c:643
#14 0x7fb618ead288 in asn1_template_ex_d2i crypto/asn1/tasn_dec.c:518
#15 0x7fb618eab9ce in asn1_item_embed_d2i crypto/asn1/tasn_dec.c:382
#16 0x7fb618eacaf5 in asn1_template_noexp_d2i crypto/asn1/tasn_dec.c:643
#17 0x7fb618ead288 in asn1_template_ex_d2i crypto/asn1/tasn_dec.c:518
#18 0x7fb618eab9ce in asn1_item_embed_d2i crypto/asn1/tasn_dec.c:382
#19 0x7fb618eadd1f in ASN1_item_ex_d2i crypto/asn1/tasn_dec.c:124
#20 0x7fb618eade35 in ASN1_item_d2i crypto/asn1/tasn_dec.c:114
#21 0x40310c in FuzzerTestOneInput fuzz/x509.c:33
#22 0x402afb in testfile fuzz/test-corpus.c:182
#23 0x402656 in main fuzz/test-corpus.c:226
#24 0x7fb618551f44 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21f44)
Indirect leak of 56 byte(s) in 1 object(s) allocated from:
#0 0x7fb61945309f in __interceptor_malloc ../../../../gcc-trunk/libsanitizer/asan/asan_malloc_linux.cpp:69
#1 0x7fb619092430 in CRYPTO_zalloc crypto/mem.c:230
#2 0x7fb618ef7561 in bn_expand_internal crypto/bn/bn_lib.c:280
#3 0x7fb618ef7561 in bn_expand2 crypto/bn/bn_lib.c:304
#4 0x7fb618ef819d in BN_bin2bn crypto/bn/bn_lib.c:454
#5 0x7fb618fd8933 in EC_GROUP_new_from_ecparameters crypto/ec/ec_asn1.c:618
#6 0x7fb618fd98e8 in EC_GROUP_new_from_ecpkparameters crypto/ec/ec_asn1.c:935
#7 0x7fb618fd9aec in d2i_ECPKParameters crypto/ec/ec_asn1.c:966
#8 0x7fb618fdace9 in d2i_ECParameters crypto/ec/ec_asn1.c:1184
#9 0x7fb618fd1fc7 in eckey_type2param crypto/ec/ec_ameth.c:119
#10 0x7fb618fd57b4 in eckey_pub_decode crypto/ec/ec_ameth.c:165
#11 0x7fb6191a9c62 in x509_pubkey_decode crypto/x509/x_pubkey.c:124
#12 0x7fb6191a9e42 in pubkey_cb crypto/x509/x_pubkey.c:46
#13 0x7fb618eac032 in asn1_item_embed_d2i crypto/asn1/tasn_dec.c:432
#14 0x7fb618eacaf5 in asn1_template_noexp_d2i crypto/asn1/tasn_dec.c:643
#15 0x7fb618ead288 in asn1_template_ex_d2i crypto/asn1/tasn_dec.c:518
#16 0x7fb618eab9ce in asn1_item_embed_d2i crypto/asn1/tasn_dec.c:382
#17 0x7fb618eacaf5 in asn1_template_noexp_d2i crypto/asn1/tasn_dec.c:643
#18 0x7fb618ead288 in asn1_template_ex_d2i crypto/asn1/tasn_dec.c:518
#19 0x7fb618eab9ce in asn1_item_embed_d2i crypto/asn1/tasn_dec.c:382
#20 0x7fb618eadd1f in ASN1_item_ex_d2i crypto/asn1/tasn_dec.c:124
#21 0x7fb618eade35 in ASN1_item_d2i crypto/asn1/tasn_dec.c:114
#22 0x40310c in FuzzerTestOneInput fuzz/x509.c:33
#23 0x402afb in testfile fuzz/test-corpus.c:182
#24 0x402656 in main fuzz/test-corpus.c:226
#25 0x7fb618551f44 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21f44)
SUMMARY: AddressSanitizer: 80 byte(s) leaked in 2 allocation(s).
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Kurt Roeckx <kurt@roeckx.be>
(Merged from openssl#18632)
…SL_CIPHER *' Fix the documentation. CLA: trivial Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Todd Short <todd.short@me.com> Reviewed-by: Paul Dale <pauli@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from openssl#18599) (cherry picked from commit d842b6e)
There are no ASIdentifiers if OPENSSL_NO_RFC3779 is defined, therefore the test cannot be compiled. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Paul Dale <pauli@openssl.org> (Merged from openssl#18634) (cherry picked from commit b76efe6) (cherry picked from commit 665ab12)
range_should_be_prefix() was misidentifying whether an IP address range should in fact be represented as a prefix. This was due to a bug introduced in commit 42d7d7d which made this incorrect change: - OPENSSL_assert(memcmp(min, max, length) <= 0); + if (memcmp(min, max, length) <= 0) + return -1; This error leads to incorrect DER being encoded/accepted. Reported by Theo Buehler (@botovq) Reviewed-by: Paul Dale <pauli@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from openssl#18524) (cherry picked from commit 30532e5) (cherry picked from commit 2c6550c)
Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Ben Kaduk <kaduk@mit.edu> (Merged from openssl#18608) (cherry picked from commit 9ef1f84)
BN_one() uses the expand function which calls malloc which may fail. All other places that reference BN_one() check the return value. The issue is triggered by a memory allocation failure. Detected by PR openssl#18355 Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Paul Dale <pauli@openssl.org> (Merged from openssl#18697) (cherry picked from commit 7fe7cc5)
aesni_ocb_encrypt and aesni_ocb_decrypt operate by having a fast-path
that performs operations on 6 16-byte blocks concurrently (the
"grandloop") and then proceeds to handle the "short" tail (which can
be anywhere from 0 to 5 blocks) that remain.
As part of initialization, the assembly initializes $len to the true
length, less 96 bytes and converts it to a pointer so that the $inp
can be compared to it. Each iteration of "grandloop" checks to see if
there's a full 96-byte chunk to process, and if so, continues. Once
this has been exhausted, it falls through to "short", which handles
the remaining zero to five blocks.
Unfortunately, the jump at the end of "grandloop" had a fencepost
error, doing a `jb` ("jump below") rather than `jbe` (jump below or
equal). This should be `jbe`, as $inp is pointing to the *end* of the
chunk currently being handled. If $inp == $len, that means that
there's a whole 96-byte chunk waiting to be handled. If $inp > $len,
then there's 5 or fewer 16-byte blocks left to be handled, and the
fall-through is intended.
The net effect of `jb` instead of `jbe` is that the last 16-byte block
of the last 96-byte chunk was completely omitted. The contents of
`out` in this position were never written to. Additionally, since
those bytes were never processed, the authentication tag generated is
also incorrect.
The same fencepost error, and identical logic, exists in both
aesni_ocb_encrypt and aesni_ocb_decrypt.
This addresses CVE-2022-2097.
Co-authored-by: Alejandro Sedeño <asedeno@google.com>
Co-authored-by: David Benjamin <davidben@google.com>
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Add test vectors for AES OCB for x86 AES-NI multiple of 96 byte issue. Co-authored-by: Alejandro Sedeño <asedeno@google.com> Co-authored-by: David Benjamin <davidben@google.com> Reviewed-by: Paul Dale <pauli@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org> Release: yes
Reviewed-by: Paul Dale <pauli@openssl.org> Release: yes
Reviewed-by: Paul Dale <pauli@openssl.org> Release: yes
dstebila
approved these changes
Jul 5, 2022
Closed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Follow upstream update to v111q
Checklist