Age | Commit message (Collapse) | Author |
|
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/17271)
|
|
bn_sqr_comba8 does for instance compute a wrong result for the value:
a=0x4aaac919 62056c84 fba7334e 1a6be678 022181ba fd3aa878 899b2346 ee210f45
The correct result is:
r=0x15c72e32 605a3061 d11b1012 3c187483 6df96999 bd0c22ba d3e7d437 4724a82f
912c5e61 6a187efe 8f7c47fc f6945fe5 75be8e3d 97ed17d4 7950b465 3cb32899
but the actual result was:
r=0x15c72e32 605a3061 d11b1012 3c187483 6df96999 bd0c22ba d3e7d437 4724a82f
912c5e61 6a187efe 8f7c47fc f6945fe5 75be8e3c 97ed17d4 7950b465 3cb32899
so the forth word of the result was 0x75be8e3c but should have been
0x75be8e3d instead.
Likewise bn_sqr_comba4 has an identical bug for the same value as well:
a=0x022181ba fd3aa878 899b2346 ee210f45
correct result:
r=0x00048a69 9fe82f8b 62bd2ed1 88781335 75be8e3d 97ed17d4 7950b465 3cb32899
wrong result:
r=0x00048a69 9fe82f8b 62bd2ed1 88781335 75be8e3c 97ed17d4 7950b465 3cb32899
Fortunately the bn_mul_comba4/8 code paths are not affected.
Also the mips64 target does in fact not handle the carry propagation
correctly.
Example:
a=0x4aaac91900000000 62056c8400000000 fba7334e00000000 1a6be67800000000
022181ba00000000 fd3aa87800000000 899b234635dad283 ee210f4500000001
correct result:
r=0x15c72e32272c4471 392debf018c679c8 b85496496bf8254c d0204f36611e2be1
0cdb3db8f3c081d8 c94ba0e1bacc5061 191b83d47ff929f6 5be0aebfc13ae68d
3eea7a7fdf2f5758 42f7ec656cab3cb5 6a28095be34756f2 64f24687bf37de06
2822309cd1d292f9 6fa698c972372f09 771e97d3a868cda0 dc421e8a00000001
wrong result:
r=0x15c72e32272c4471 392debf018c679c8 b85496496bf8254c d0204f36611e2be1
0cdb3db8f3c081d8 c94ba0e1bacc5061 191b83d47ff929f6 5be0aebfc13ae68d
3eea7a7fdf2f5758 42f7ec656cab3cb5 6a28095be34756f2 64f24687bf37de06
2822309cd1d292f8 6fa698c972372f09 771e97d3a868cda0 dc421e8a00000001
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/17258)
(cherry picked from commit 336923c0c8d705cb8af5216b29a205662db0d590)
|
|
This happened after an out of memory error:
CRYPTO_THREAD_write_lock may hang in OBJ_NAME_add.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/17236)
|
|
OpenSSL assumes AT_HWCAP = 16 (as on Linux), but on FreeBSD AT_HWCAP = 25
Switch to using AT_HWCAP, and setting it to 16 if it is not defined.
OpenSSL calls elf_auxv_info() with AT_CANARY which returns ENOENT
resulting in all ARM acceleration features being disabled.
CLA: trivial
Reviewed-by: Ben Kaduk <kaduk@mit.edu>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/17082)
(cherry picked from commit c1dabe26e3e96cdce0ffc929e9677840ad089ba5)
|
|
There was no string present for ERR_R_PASSED_INVALID_ARGUMENT
Reviewed-by: David von Oheimb <david.von.oheimb@siemens.com>
(Merged from https://github.com/openssl/openssl/pull/17069)
|
|
Use the address of the bind function as a DYNAMIC_ID,
since the true name of the engine is not known
before the bind function returns,
but invoking the bind function before the engine
is unloaded results in memory corruption.
Fixes #17023
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/17073)
(cherry picked from commit e2571e02d2b0cd83ed1c79d384fe941f27e603c0)
|
|
EVP_PKEY_set_alias_type(pkey, EVP_PKEY_SM2) will change pkey->type to EVP_PKEY_SM2
CLA: trivial
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/17015)
|
|
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/16974)
(cherry picked from commit 09235289c377ff998964bb6b074bb2a3ad768fd2)
|
|
pkey_set_type should not consume the ENGINE references that may be
passed to it.
Fixes #16757
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/16860)
|
|
An EVP_CONTEXT with zero cipher but non-zero engine,
and/or cipher_data is possible if an error happens
in EVP_CTRL_INIT or in EVP_CTRL_COPY, the error handling
will just clear the cipher in that case.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/16756)
|
|
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/16524)
(cherry picked from commit 485d0790ac1a29a0d4e7391d804810d485890376)
|
|
'__int64', not 'int64_t'
Ref: commit 2e5cdbc18a1a26bfc817070a52689886fa0669c2
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/16557)
|
|
The compiler says that 'unsigned long long' isn't the same as
'unsigned __int64'. Sure, and considering that crypto/rand/rand_vms.c
is specific VMS only code, it's easy to just change the type to the
exact same as what's specified in the system headers.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/15613)
|
|
When building the certificate chain, prioritise any Cert(0) Full(0)
certificates from TLSA records over certificates received from the peer.
This is important when the server sends a cross cert, but TLSA records include
the underlying root CA cert. We want to construct a chain with the issuer from
the TLSA record, which can then match the TLSA records (while the associated
cross cert may not).
Reviewed-by: Tomáš Mráz <tomas@openssl.org>
|
|
(kfreebsd-amd64, kfreebsd-i386). The error reported by the compiler
is:
../crypto/uid.c: In function 'OPENSSL_issetugid':
../crypto/uid.c:50:22: error: 'AT_SECURE' undeclared (first use in this function)
50 | return getauxval(AT_SECURE) != 0;
| ^~~~~~~~~
This commit changes the code to use the freebsd code in this case.
This fixes the compilation.
CLA: trivial
Reviewed-by: Ben Kaduk <kaduk@mit.edu>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/16477)
(cherry picked from commit 3a1fa0116a92235ba200228e4bb60d6a3a7f4113)
|
|
Fixes #16428
Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/16441)
|
|
Some curves don't have an associated OID: for those we should not
default to `OPENSSL_EC_NAMED_CURVE` encoding of parameters and instead
set the ASN1 flag to `OPENSSL_EC_EXPLICIT_CURVE`.
This is a follow-up to https://github.com/openssl/openssl/pull/12312
(cherry picked from commit 7aa3dfc42104588f65301d20324388ac2c9a6b11)
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/12457)
|
|
This fixes the following error with gcc10 under strict ANSI conditions:
.../crypto/bio/bss_dgram.c:373:20: error: 'const struct in6_addr' has no member named 's6_addr32'
CLA: trivial
Fixes #16449
Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/16451)
(cherry picked from commit e8e1f6d1a9e599d575431f559200018b8f822e0f)
|
|
ubsan found undefined pointer addtions in
crypto/bio/bss_mem.c (mem_ctrl),
crypto/pem/pem_lib.c (PEM_read_bio_ex),
test/testutil/format_output.c (test_fail_string_common,
test_fail_memory_common).
Mostly a straight back-port-of: a07dc81
Additionally enable the ubsan run-checker, to prevent regressions.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Nicola Tuveri <nic.tuv@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/16423)
|
|
CLA: trivial
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/16403)
|
|
issue #16407 #16408
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/16409)
|
|
CLA: trivial
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/16347)
(cherry picked from commit 62bae84d4587ec9a56d0ce830e36e4a5b2fa8a33)
|
|
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/16382)
|
|
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/16375)
|
|
Reviewed-by: Richard Levitte <levitte@openssl.org>
|
|
Reviewed-by: Richard Levitte <levitte@openssl.org>
|
|
Previously there was no check that the supplied buffer was large enough.
It was just assumed to be sufficient. Instead we should check and fail if
not.
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Nicola Tuveri <nic.tuv@gmail.com>
|
|
Previously the length of the SM2 plaintext could be incorrectly calculated.
The plaintext length was calculated by taking the ciphertext length and
taking off an "overhead" value.
The overhead value was assumed to have a "fixed" element of 10 bytes.
This is incorrect since in some circumstances it can be more than 10 bytes.
Additionally the overhead included the length of two integers C1x and C1y,
which were assumed to be the same length as the field size (32 bytes for
the SM2 curve). However in some cases these integers can have an additional
padding byte when the msb is set, to disambiguate them from negative
integers. Additionally the integers can also be less than 32 bytes in
length in some cases.
If the calculated overhead is incorrect and larger than the actual value
this can result in the calculated plaintext length being too small.
Applications are likely to allocate buffer sizes based on this and therefore
a buffer overrun can occur.
CVE-2021-3711
Issue reported by John Ouyang.
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Nicola Tuveri <nic.tuv@gmail.com>
|
|
Previously if an error path is entered a leak could result.
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
|
|
If FUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION is defined then we don't NUL
terminate ASN1_STRING datatypes. This shouldn't be necessary but we add it
any for safety in normal builds.
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
|
|
Check that there's at least one byte in params->base before trying to
read it.
CVE-2021-3712
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
|
|
ASN.1 strings may not be NUL terminated. Don't assume they are.
CVE-2021-3712
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
|
|
ASN.1 strings may not be NUL terminated. Don't assume they are.
CVE-2021-3712
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
|
|
ASN.1 strings may not be NUL terminated. Don't assume they are.
CVE-2021-3712
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
|
|
ASN.1 strings may not be NUL terminated. Don't assume they are.
CVE-2021-3712
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
|
|
ASN.1 strings may not be NUL terminated. Don't assume they are.
CVE-2021-3712
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
|
|
ASN.1 strings may not be NUL terminated. Don't assume they are.
CVE-2021-3712
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
|
|
(cherry picked from commit 64fac96de81d3dc19cc0c9045c341f0dec818075)
Reviewed-by: Nicola Tuveri <nic.tuv@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/16336)
|
|
Fixes #16331
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
Reviewed-by: Kurt Roeckx <kurt@roeckx.be>
(Merged from https://github.com/openssl/openssl/pull/16333)
|
|
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 https://github.com/openssl/openssl/pull/16292)
|
|
This reverts commit 006906cddda37e24a66443199444ef4476697477.
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/16308)
|
|
This reverts commit ea26844c4f624ef515d9228d3b623761a369b049.
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/16308)
|
|
Fixes #10777
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/16130)
(cherry picked from commit 40184c96103a388209939c1c19920971c05bb78c)
|
|
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 https://github.com/openssl/openssl/pull/16108)
(cherry picked from commit c5dc9ab965f2a69bca964c709e648158f3e4cd67)
|
|
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 https://github.com/openssl/openssl/pull/16039)
|
|
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/16027)
|
|
Fixes #16026
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/16027)
|
|
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 3a1d2b59522163ebb83bb68e13c896188dc222c6)
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/15999)
|
|
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 #15982
Reviewed-by: Nicola Tuveri <nic.tuv@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/15991)
(cherry picked from commit 105c83150f15af3f78ea0758859062842bdbe30e)
|
|
backport of #15924
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/15935)
|