Signed-off-by: lan1120 <lanming@huawei.com>
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/23045)
As there is no default case for a->type or b->type in the switch()
statements, if the type does not fall into any defined cases
then memcmp() will be done on garbage data.
Adding default cases in both switches.
CLA: trivial
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/23082)
The [LP64D ABI][1] requires the floating-point registers f24-f31
(aka fs0-fs7) callee-saved. The low 64 bits of a LSX/LASX vector
register aliases with the corresponding FPR, so we must save and restore
the callee-saved FPR when we writes into the corresponding vector
register.
This ABI breakage can be easily demonstrated by injecting the use of a
saved FPR into the test in bio_enc_test.c:
static int test_bio_enc_chacha20(int idx)
{
register double fs7 asm("f31") = 114.514;
asm("#optimize barrier":"+f"(fs7));
return do_test_bio_cipher(EVP_chacha20(), idx) && fs7 == 114.514;
}
So fix it. To make the logic simpler, jump into the scalar
implementation earlier when LSX and LASX are not enumerated in AT_HWCAP,
or the input is too short.
[1]: https://github.com/loongson/la-abi-specs/blob/v2.20/lapcs.adoc#floating-point-registers
Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/22817)
The newly introduced test case do not work
when configured with no-des, fix that by
choosing -aes128 as cipher.
Fixes ffed597882 ("cms: avoid intermittent test failure")
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/23086)
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: David von Oheimb <david.von.oheimb@siemens.com>
(Merged from https://github.com/openssl/openssl/pull/21281)
Also add missing getter functionss OSSL_CMP_{CTX,HDR}_get0_geninfo_ITAVs() to CMP API.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: David von Oheimb <david.von.oheimb@siemens.com>
(Merged from https://github.com/openssl/openssl/pull/21281)
The following entries should be still applied.
Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/23048)
Even if some configuration entry is incorrect, do not
skip the remaining ones.
Fixes#20789
Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/23048)
TLSv1.3 includes an extra byte after the payload for the content type.
We should incorporate that in the calculation of the default buffer length.
Fixes#23015
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Hugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/23021)
If you decrypt a random input using RSAES-PKCS-v1_5, then there is a
non-negligible chance that the result will look like a valid plaintext
(that is why RSAES-PKCS-v1_5 shouldn't be used anymore). This was the
cause of an intermittent failure in a test that did a cms-encrypt
operation targetting multiple recipients.
The failure happened during key-only decrypt. The recipient decrypts
every RSA ciphertext -- only one is supposed to decrypt successfully,
which would reveal the right content-key. Occassionally, more than
one decrypted successfully.
Update the test by specifying the recipient cert in the decrypt op
(this avoids looping over all RSA ciphertexts).
Add a new test to get coverage for key-only decrypt, but use RSA-OAEP
during the encrypt op.
Fixes https://github.com/openssl/project/issues/380
Testing:
$ make TESTS='test_cms' test
Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/23055)
In commit d7c0fc5b1a we removed L_ENDIAN
definition for guessed linux64-loongarch64 as it had caused an
inconsistency between configurations with and without explicit
specifying linux64-loongarch64. Now add it back to the proper location.
Unlike MIPS or RISC-V, LoongArch is always little-endian [1].
By the way, change "LOONGARCH" to "LoongArch" in a comment as LOONGARCH
should only appear in the identifiers of macros, constants, etc.
[1]:https://loongson.github.io/LoongArch-Documentation/LoongArch-Vol1-EN.html#endian
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/23064)
In the command `nmake TEST='foo' test`, on Windows the runner
will look for test `'foo'` and complain about the test not being found
(due to the extraneous single quotes), whereas with `nmake TEST="foo" test`,
the test `foo` will be correctly found.
CLA: trivial
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/23059)
EVP_MAC_CTX_get_mac_size() cannot be called on older
unfixed versions before EVP_MAC_init().
Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/23006)
gh_gen_type_common_set_params looks up a dsa contexts gen_type using
name2id, but if it returns error, we inadvertently set gctx->gen_type to
-1, which is an invalid value, which may lead to improper behavior in
future calls, in the event that said future calls preform an operation
of the form;
if (gen_type == <VALID VALUE>) {
do_stuff
else {
do_other_stuff
}
Technically it is not correct to continue with the operations on the
gen context after failed parameters setting but this makes it more
predictable.
Fix it by assigning the result of a lookup to a stack variable, and only
update gctx->gen_value if the lookup returns a non-failing value
In leiu of testing this specific case, also add an ossl_assert in dsa_gen
to validate the gen_val input prior to continuing, should other code
points attempt to do the same thing
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/22991)
gh_gen_type_common_set_params looks up a dh contexts gen_type using
name2id, but if it returns error, we set gctx->gen_type to -1, which
is an invalid value, which may lead to undefined behavior in
future calls, in the event that said future calls preform an operation
of the form;
if (gen_type == <VALID VALUE>) {
do_stuff
else {
do_other_stuff
}
Technically it is not correct to continue with the operations on the
gen context after failed parameters setting but this makes it more
predictable.
Fix it by assigning the result of a lookup to a stack variable, and only
update gctx->gen_value if the lookup returns a non-failing value
In leiu of testing this specific case, also add an ossl_assert in dh_gen
to validate the gen_val input prior to continuing, should other code
points attempt to do the same thing
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/22991)
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/22911)
In the event that a config file contains this sequence:
=======
openssl_conf = openssl_init
config_diagnostics = 1
[openssl_init]
oid_section = oids
[oids]
testoid1 = 1.2.3.4.1
testoid2 = A Very Long OID Name, 1.2.3.4.2
testoid3 = ,1.2.3.4.3
======
The leading comma in testoid3 can cause a heap buffer overflow, as the
parsing code will move the string pointer back 1 character, thereby
pointing to an invalid memory space
correct the parser to detect this condition and handle it by treating it
as if the comma doesn't exist (i.e. an empty long oid name)
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/22957)
At some point the asn1parse applet was changed to default the inform to
PEM, and defalt input file to stdin. Doing so broke the -genstr|conf options,
in that, before we attempt to generate an ASN1 block from the provided
genstr string, we attempt to read a PEM input from stdin. As a result,
this command:
openssl asn1parse -genstr OID:1.2.3.4
hangs because we are attempting a blocking read on stdin, waiting for
data that never arrives
Fix it by giving priority to genstr|genconf, such that, if set, will just run
do_generate on that string and exit
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/22957)
