Fix the gcc build warning from conf_sap.c:
variable flags set but not used [-Wunused-but-set-variable]
variable appname set but not used [-Wunused-but-set-variable]
variable filename set but not used [-Wunused-but-set-variable]
CLA: trivial
Signed-off-by: Gang Chen <gang.c.chen@intel.com>
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/20347)
The test tries to use DES but that may not be available.
But for the purpose of regression testing CVE-2023-0215
the cipher is not relevant, so we use AES-128 instead.
Fixes#20249
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Todd Short <todd.short@me.com>
(Merged from https://github.com/openssl/openssl/pull/20276)
(cherry picked from commit c400a1fe477b44a5eacbad2be8d50f2eaa92925c)
_umul128() is x86_64 (x64) only, while __umulh() works everywhere, but
doesn't generate optimal code on x64
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/20244)
(cherry picked from commit 075652f224479dad2e64b92e791b296177af8705)
If the aux->asn1_cb() call fails in BIO_new_NDEF then the "out" BIO will
be part of an invalid BIO chain. This causes a "use after free" when the
BIO is eventually freed.
Based on an original patch by Viktor Dukhovni and an idea from Theo
Buehler.
Thanks to Octavio Galland for reporting this issue.
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Call PEM_read_bio_ex() and expect a failure. There should be no dangling
ptrs and therefore there should be no double free if we free the ptrs on
error.
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Hugo Landau <hlandau@openssl.org>
In the event of a failure in PEM_read_bio_ex() we free the buffers we
allocated for the header and data buffers. However we were not clearing
the ptrs stored in *header and *data. Since, on success, the caller is
responsible for freeing these ptrs this can potentially lead to a double
free if the caller frees them even on failure.
Thanks to Dawei Wang for reporting this issue.
Based on a proposed patch by Kurt Roeckx.
CVE-2022-4450
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Hugo Landau <hlandau@openssl.org>
A timing based side channel exists in the OpenSSL RSA Decryption
implementation which could be sufficient to recover a plaintext across
a network in a Bleichenbacher style attack. To achieve a successful
decryption an attacker would have to be able to send a very large number
of trial messages for decryption. The vulnerability affects all RSA
padding modes: PKCS#1 v1.5, RSA-OEAP and RSASVE.
Patch written by Dmitry Belyavsky and Hubert Kario
CVE-2022-4304
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
If the user specifies an alternative build file than the default, this
alternative is recorded in $config{build_file}, not $target{build_file}.
Therefore, the former should be used, leaving the latter as a mere default.
This is a bug.
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/20174)
Using floating point is not supported in UEFI and can cause build
problems, for example due to SSE being disabled and x64 calling
convention passing floats in SSE registers.
Avoid those problems by not compiling the formating code for floating
point numbers.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/19738)
The by_dir certificate/CRL lookup code uses an OPENSSL_STACK to track
how many sequentially numbered CRL files have been loaded for a given
X509_NAME hash which is being requested. This avoids loading already
loaded CRL files and repeated stat() calls.
This OPENSSL_STACK is searched using sk_find, however this mutates
the OPENSSL_STACK unless it is known to be sorted. This operation
therefore requires a write lock, which was not taken.
Fix this issue by sorting the OPENSSL_STACK whenever it is mutated. This
guarantees no mutation will occur during sk_find. This is chosen over
taking a write lock during sk_find as retrieving a CRL by X509_NAME is
assumed to be a hotter path than the case where a new CRL is installed.
Also optimise the code by avoiding creating the structure to track the
last CRL file sequence number in the circumstance where it would match
the initial value, namely where no CRL with the given hash is installed.
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/20127)
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Hugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/20087)
Some ciphers/protocol versions have an explicit IV. We need to make sure we
have sufficient room for it in the underlying buffer.
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Hugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/20087)
Test that sending large app data records works correctly.
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Hugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/20087)
Byte swapping code incorrectly uses the number of AES rounds to swap expanded
AES key, while swapping only a single dword in a loop, resulting in swapped
key and partially swapped expanded keys, breaking AES encryption and
decryption on VIA Padlock hardware.
This commit correctly sets the number of swapping loops to be done.
Fixes#20073
CLA: trivial
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/20077)
(cherry picked from commit 7331e7ef79fe4499d81cc92249e9c97e9ff9291a)
Otherwise the alloca can cause an exception.
Issue reported by Jiayi Lin.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/19735)
If the cipher being used in ossl_cms_EncryptedContent_init_bio() has no
associated OID then we should report an error rather than continuing on
regardless. Continuing on still ends up failing - but later on and with a
more cryptic error message.
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/19920)
Some things that may go wrong in asn1_bio_write() are serious errors
that should be reported as -1, rather than 0 (which just means "we wrote
no data").
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/19920)
If the BIO unexpectedly fails to flush then SMIME_crlf_copy() was not
correctly reporting the error. We modify it to properly propagate the
error condition.
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/19920)
If an error occurs during a flush on a BIO_f_cipher() then in some cases
we could get into an infinite loop. We add a check to make sure we are
making progress during flush and exit if not.
This issue was reported by Octavio Galland who also demonstrated an
infinite loop in CMS encryption as a result of this bug.
The security team has assessed this issue as not a CVE. This occurs on
*encryption* only which is typically processing trusted data. We are not
aware of a way to trigger this with untrusted data.
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/19920)
Due to the logic flaw, possible test failures
in this test case might be ignored.
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/19929)
(cherry picked from commit 42061268ee8f9ae0555d522870740fc91b744f4f)
If PKCS8_pkey_set0 fails, the memory in rk need to be clear freed
otherwise it is owned by the PKCS8_PRIV_KEY_INFO.
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Todd Short <todd.short@me.com>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/19694)
Stitched ciphersuites can grow by more during encryption than the code
allowed for. We fix the calculation and add an assert to check we go it
right.
Also if we are adding the MAC independently of the cipher algorithm then
the encryption growth will not include that MAC so we should remove it
from the amount of bytes that we reserve for that growth. Otherwise we
might exceed our buffer size and the WPACKET_reserve operation will
fail.
Note that this is not a security issue. Even though we can overflow the
amount of bytes reserved in the WPACKET for the encryption, the underlying
buffer is still big enough.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Hugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/19585)
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/19654)
(cherry picked from commit 43086b1bd48958ce95fadba8459ad88675da4fdf)
Note: The private key is test/certs/root-ed25519.privkey.pem
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/19654)
(cherry picked from commit 42f917432999b34ad8618ae03a5f199738a2b5ba)
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/19581)
(cherry picked from commit ec33ed712665ca65cabcd87d446e5db79a64379e)
SYS$GETTIM_PREC is a very new function, only available on OpenVMS v8.4.
OpenSSL binaries built on OpenVMS v8.4 become unusable on older OpenVM
versions, but building for the older CRTL version will make the high
precision time functions unavailable.
Tests have shown that on Alpha and Itanium, the time update granularity
between SYS$GETTIM and SYS$GETTIM_PREC is marginal, so the former plus
a sequence number turns out to be better to guarantee a unique nonce.
Fixes#18727
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Hugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/18730)
If rule_str ended in a "-", "l" was incremented one byte past the
end of the buffer. This resulted in an out-of-bounds read when "l"
is dereferenced at the end of the loop. It is safest to just return
early in this case since the condition occurs inside a nested loop.
CLA: trivial
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/19166)
(cherry picked from commit 428511ca66670e169a0e1b12e7540714b0be4cf8)
Also change B< to I< in {CMS,PKCS7}_verify.pod, PKCS7_sign{,_add_signer}.pod
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: David von Oheimb <david.von.oheimb@siemens.com>
(Merged from https://github.com/openssl/openssl/pull/19108)
(cherry picked from commit 312a6b3a0327a986344c85aa6bc43e135d70bc6c)
The IRIX mips64-cpu, n32-abi configurations include SIXTY_FOUR_BIT in bn_ops,
but it is missing from mips64*-linux-*abin32 (which OpenSSL calls
"linux-mips64"). This causes heap corruption when verifying TLS certificates
(which tend to be RSA-signed) with openssl 1.1.1q:
```
nix@oak:~$ /nix/store/4k04dh6a1zs6hxiacwcg4a4nvxvgli2j-openssl-mips64el-unknown-linux-gnuabin32-1.1.1q-bin/bin/openssl s_client -host www.google.com -port 443free(): invalid pointer
Aborted
```
and a slightly different failure with current HEAD:
```
nix@oak:~$ /nix/store/9bqxharxajsl9fid0c8ls6fb9wxp8kdc-openssl-mips64el-unknown-linux-gnuabin32-1.1.1q-bin/bin/openssl s_client -host www.google.com -port 443
Connecting to 142.250.180.4
CONNECTED(00000003)
Fatal glibc error: malloc assertion failure in sysmalloc: (old_top == initial_top (av) && old_size == 0) || ((unsigned long) (old_size) >= MINSIZE && prev_inuse (old_top) && ((unsigned long) old_end & (pagesize - 1)) == 0)
Aborted
```
Applying this patch and recompiling produces the expected output instead of a
crash.
Note that Gentoo (and to my knowledge all other other distributions which
support mips64n32) use the `linux-generic32` configuration, which uses only
32-bit arithmetic (rather than full 64-bit arithmetic) and lacks assembler
implementations for the SHA hash functions:
https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-libs/openssl/files/gentoo.config-1.0.2#n102
For support in nixpkgs we would like to use the full 64-bit integer registers
and perlasm routines, so I'm submitting this upstream as well.
Fixes#19319
CLA: trivial
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/19320)
(cherry picked from commit d250e8563fa400fd3d9b93cff609c7503149b908)
We need to reencode X509_req_info_st if member data updated.
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/18879)
