add rsa_sup_mul.c from CVE-2022-4304 fix https://github.com/openssl/openssl/commit/43d8f88511991533f53680a751e9326999a6a31fSigned-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: NDmitry Belyavskiy <beldmit@gmail.com>
Reviewed-by: NTomas Mraz <tomas@openssl.org>
Signed-off-by: Ncode4lala <fengziteng2@huawei.com>

Merge pull request !85 from wanghao-free/OpenHarmony-3.0-LTS

Signed-off-by: Nwanghao-free <wanghao453@h-partners.com>

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>

Merge pull request !81 from wanghao-free/OpenHarmony-3.0-LTS

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

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>

Merge pull request !63 from zhao_zhen_zhou/cherry-pick-1657509349

CVE-2022-2097
Signed-off-by: Nzhao_zhen_zhou <zhaozhenzhou@huawei.com>

Merge pull request !56 from HaixiangW/cherry-pick-1656070588

fix CVE-2022-2068
Signed-off-by: Nhaixiangw <wanghaixiang@huawei.com>

Merge pull request !48 from HaixiangW/cherry-pick-1652666642

fix CVE-2022-1292
Signed-off-by: Nhaixiangw <wanghaixiang@huawei.com>

Merge pull request !34 from HaixiangW/cherry-pick-1647873389

fix CVE-2022-0778
Signed-off-by: Nhaixiangw <wanghaixiang@huawei.com>

Merge pull request !29 from HaixiangW/cherry-pick-1644398698

openssl CVE-2021-4160
Signed-off-by: Nhaixiangw <wanghaixiang@huawei.com>

Merge pull request !26 from 33/OpenHarmony-3.0-LTS

Signed-off-by: NSang_Sang33 <wangzhu15@huawei.com>

Merge pull request !23 from zhao_zhen_zhou/cherry-pick-1632993416

修改OAT.xml文件中的过滤规则中的路径
Signed-off-by: Nzhao-zhen-zhou <zhaozhenzhou@huawei.com>

Merge pull request !19 from zhao_zhen_zhou/cherry-pick-1632971214

添加OAT.xml文件
Signed-off-by: Nzhao-zhen-zhou <zhaozhenzhou@huawei.com>

Merge pull request !16 from HaixiangW/myfeature

Signed-off-by: Nwanghaixiang <wanghaixiang@huawei.com>

Merge pull request !13 from HJ/master

Signed-off-by: NHJ <huangjun42@huawei.com>

Signed-off-by: NHJ <huangjun42@huawei.com>

Merge pull request !11 from HJ/0810

Signed-off-by: NHJ <huangjun42@huawei.com>

Merge pull request !6 from HJ/master

Merge pull request !5 from HJ/master

Change-Id: Ia29013889dd9f784266e06998eb6c61bb37441cc

Description: add COPYRIGHT.OpenSource files
Team:OTHERS
Feature or Bugfix:Bugfix
Binary Source:No
PrivateCode(Yes/No):No

Change-Id: Ib7349a14e12eb5e229988bb4f5a57f05714bf78e
Reviewed-on: http://mgit-tm.rnd.huawei.com/10077179Tested-by: Npublic jenkins <public_jenkins@notesmail.huawei.com>
Reviewed-by: Nhouyuezhou 00386575 <hou@huawei.com>
Reviewed-by: Npuxing 00257459 <puxing@huawei.com>