Merge pull request !77 from code4lala/master

Signed-off-by: Ncode4lala <fengziteng2@huawei.com>

Signed-off-by: Ncode4lala <fengziteng2@huawei.com>
Change-Id: I1be72a32ac34ab145541069582d3e7299a54000b

Signed-off-by: Ncode4lala <fengziteng2@huawei.com>
Change-Id: I488711240cdb6fcac66e5660a5695513ac47a816

The function was incorrectly documented as enabling policy checking.

Fixes: CVE-2023-0466
Reviewed-by: NMatt Caswell <matt@openssl.org>
Reviewed-by: NPaul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/20563)
Signed-off-by: Ncode4lala <fengziteng2@huawei.com>
Change-Id: I515b0c03074af5cf5a6f5e72bcec4a2d6642707a

This reverts commit 9aa4be691f5c73eb3c68606d824c104550c053f7 and removed the
redundant flag setting.

Fixes #19643

Fixes LOW CVE-2022-3996
Reviewed-by: NDmitry Belyavskiy <beldmit@gmail.com>
Reviewed-by: NTomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/19652)

(cherry picked from commit 4d0340a6d2f327700a059f0b8f954d6160f8eef5)
Signed-off-by: Ncode4lala <fengziteng2@huawei.com>
Change-Id: I1013e00e8fe7c7975cf8e6dd4db380f37179660d

A security vulnerability has been identified in all supported versions
of OpenSSL related to the verification of X.509 certificate chains
that include policy constraints.  Attackers may be able to exploit this
vulnerability by creating a malicious certificate chain that triggers
exponential use of computational resources, leading to a denial-of-service
(DoS) attack on affected systems.

Fixes CVE-2023-0464
Reviewed-by: NTomas Mraz <tomas@openssl.org>
Reviewed-by: NShane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/20568)
Signed-off-by: Ncode4lala <fengziteng2@huawei.com>
Change-Id: Ia84b5d25d543af1e61661fced02acd92b22afe5a

Signed-off-by: Ncode4lala <fengziteng2@huawei.com>

Signed-off-by: Ncode4lala <fengziteng2@huawei.com>

Signed-off-by: Ncode4lala <fengziteng2@huawei.com>

Signed-off-by: Ncode4lala <fengziteng2@huawei.com>

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: NMatt Caswell <matt@openssl.org>
Reviewed-by: NTomas Mraz <tomas@openssl.org>
Signed-off-by: Ncode4lala <fengziteng2@huawei.com>
Change-Id: Ib81f15484fa3374bf5f50baece50bb36d105d6d7

Fixes CVE-2023-0217

When attempting to do a BN_Copy of params->p there was no NULL check.
Since BN_copy does not check for NULL this is a NULL reference.

As an aside BN_cmp() does do a NULL check, so there are other checks
that fail because a NULL is passed. A more general check for NULL params
has been added for both FFC public and private key validation instead.
Reviewed-by: NMatt Caswell <matt@openssl.org>
Reviewed-by: NPaul Dale <pauli@openssl.org>
Reviewed-by: NTomas Mraz <tomas@openssl.org>
Signed-off-by: Ncode4lala <fengziteng2@huawei.com>
Change-Id: I7086365d9f51b6f36fcfb79a45d36f8d032e1f22

Original author: Nevine Ebeid (Amazon)
Fixes: CVE-2023-1255

The buffer overread happens on decrypts of 4 mod 5 sizes.
Unless the memory just after the buffer is unmapped this is harmless.
Reviewed-by: NPaul Dale <pauli@openssl.org>
Reviewed-by: NTom Cosgrove <tom.cosgrove@arm.com>
(Merged from https://github.com/openssl/openssl/pull/20759)

(cherry picked from commit 72dfe46550ee1f1bbfacd49f071419365bc23304)
Signed-off-by: Ncode4lala <fengziteng2@huawei.com>
Change-Id: I636543b8cf34e1edaeee4d1c0d5617eb500a24a6

Fixes CVE-2023-0216
Reviewed-by: NShane Lontis <shane.lontis@oracle.com>
Reviewed-by: NPaul Dale <pauli@openssl.org>
Signed-off-by: Ncode4lala <fengziteng2@huawei.com>
Change-Id: Ib4aac57064b9860c1960a66e3cbeac43ff929fe4

Reviewed-by: NPaul Dale <pauli@openssl.org>
Reviewed-by: NTomas Mraz <tomas@openssl.org>
Change-Id: If27a355635b2da681abac1d757386a5c9dfcdae3
Signed-off-by: Ncode4lala <fengziteng2@huawei.com>

These calls invoke EVP_DigestInit() which can fail for digests
with implicit fetches. Subsequent EVP_DigestUpdate() from BIO_write()
or EVP_DigestFinal() from BIO_read() will segfault on NULL
dereference. This can be triggered by an attacker providing
PKCS7 data digested with MD4 for example if the legacy provider
is not loaded.

If BIO_set_md() fails the md BIO cannot be used.

CVE-2023-0401
Reviewed-by: NPaul Dale <pauli@openssl.org>
Reviewed-by: NDmitry Belyavskiy <beldmit@gmail.com>
Signed-off-by: Ncode4lala <fengziteng2@huawei.com>
Change-Id: Id19000b7a7fc2dbe28e9d41fb66d496ec7ca9ef1

Even though we check the leaf cert to confirm it is valid, we
later ignored the invalid flag and did not notice that the leaf
cert was bad.

Fixes: CVE-2023-0465
Reviewed-by: NHugo Landau <hlandau@openssl.org>
Reviewed-by: NTomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/20587)
Signed-off-by: Ncode4lala <fengziteng2@huawei.com>
Change-Id: I510a81e2e970638eb61ebd1d78c07f2559d15c18

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: NPaul Dale <pauli@openssl.org>
Reviewed-by: NTomas Mraz <tomas@openssl.org>
Signed-off-by: Ncode4lala <fengziteng2@huawei.com>
Change-Id: I9194a044eccbf5410227b2e833dfd2221ffa3735

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: NPaul Dale <pauli@openssl.org>
Reviewed-by: NHugo Landau <hlandau@openssl.org>
Signed-off-by: Ncode4lala <fengziteng2@huawei.com>
Change-Id: Ic4a32fd3b5cbebfcc20bb93db250d44a60f00dd3

This function assumes that if the "gen" is an OtherName, then the "base"
is a rfc822Name constraint. This assumption is not true in all cases.
If the end-entity certificate contains an OtherName SAN of any type besides
SmtpUtf8Mailbox and the CA certificate contains a name constraint of
OtherName (of any type), then "nc_email_eai" will be invoked, with the
OTHERNAME "base" being incorrectly interpreted as a ASN1_IA5STRING.

Reported by Corey Bonnell from Digicert.

CVE-2022-4203
Reviewed-by: NPaul Dale <pauli@openssl.org>
Reviewed-by: NHugo Landau <hlandau@openssl.org>
Reviewed-by: NTomas Mraz <tomas@openssl.org>
Signed-off-by: Ncode4lala <fengziteng2@huawei.com>
Change-Id: I008cc36abe7c7957312525e5ee002fdc42737649

Fix llvm-15 build error, compile libssl_openssl.z.so to the updater image for wpa to use, ssl_config -> ssl_config_private
Signed-off-by: Ncode4lala <fengziteng2@huawei.com>

Signed-off-by: Ncode4lala <fengziteng2@huawei.com>
Change-Id: I5007924c8986ac134db278f7694b5bfcfa84c515

Signed-off-by: Ncode4lala <fengziteng2@huawei.com>
Change-Id: I729658f16c6d6fade57f4c327bc3f16beee3f0e4

Signed-off-by: Ncode4lala <fengziteng2@huawei.com>
Change-Id: Ie496270d939f787d14670a7851dbde783b6a4335

Signed-off-by: Ncode4lala <fengziteng2@huawei.com>
Change-Id: I5913041696f769307c08cf87c28ba70e7870465d

Signed-off-by: Ncode4lala <fengziteng2@huawei.com>
Change-Id: Iac985d5c82924614240d81262888975e29fcb8f6

Signed-off-by: Ncode4lala <fengziteng2@huawei.com>
Change-Id: Ife869932de66a5f0f9e5f4671a7946ac98a08499

Signed-off-by: Ncode4lala <fengziteng2@huawei.com>
Change-Id: If65075f86690553d4318c6bc14b7790ec66fca48

Signed-off-by: Ncode4lala <fengziteng2@huawei.com>
Change-Id: Ie41407008ba50276a06b3f043b191f73c800b640

Signed-off-by: Ncode4lala <fengziteng2@huawei.com>
Change-Id: I8be4f5c60df0ad52e0fc4abbb938f510a0cfffa8

Signed-off-by: Ncode4lala <fengziteng2@huawei.com>
Change-Id: I9a08705b953a1efc1eba7532ca883a93c21bed39

Signed-off-by: Ncode4lala <fengziteng2@huawei.com>
Change-Id: Ifcfc694b49a61f5e70672e574e868ba0a907f664

Signed-off-by: Ncode4lala <fengziteng2@huawei.com>
Change-Id: Id1de7fb5568d390a0ad450481d48bdb78a0f9649

Signed-off-by: Ncode4lala <fengziteng2@huawei.com>
Change-Id: I83ec360d829238be6afd3b4f3985d8dceac4888f

Signed-off-by: Ncode4lala <fengziteng2@huawei.com>
Change-Id: I67c01812a50086aa0c209d510e17d02ffcc9b4fa

Signed-off-by: Ncode4lala <fengziteng2@huawei.com>
Change-Id: I2e04e618c067af3635f1b18076e7817ae0a23557

Signed-off-by: Ncode4lala <fengziteng2@huawei.com>
Change-Id: I89fc88a46e22fdc619d1796a09718d89f88857bd

Signed-off-by: Ncode4lala <fengziteng2@huawei.com>
Change-Id: Ie105d84584e24b23922d15deb9256b0dac0e8a57

Signed-off-by: Ncode4lala <fengziteng2@huawei.com>
Change-Id: Ia207049b9291a11846e5025cec461e4d76c25699