!209 Fix the issue that the gBS->LoadImage pointer was empty.

From: @fly_fzc 
Reviewed-by: @HuaxinLuGitee 
Signed-off-by: @HuaxinLuGitee

Feature-Convert-file-name-from-wide-char-to-narrow-char.patch

@@ -0,0 +1,62 @@
+From 5983ad49a335b8472c04a4cf1b8244df0ae77b6b Mon Sep 17 00:00:00 2001
+From: jinlun <jinlun@huawei.com>
+Date: Thu, 13 Jul 2023 19:43:22 +0800
+Subject: [PATCH] Convert file name from wide char to narrow char
+
+---
+ tpcm.c | 21 +++++++++++++++++++--
+ 1 file changed, 19 insertions(+), 2 deletions(-)
+
+diff --git a/tpcm.c b/tpcm.c
+index fbd1da6..e98b3d7 100644
+--- a/tpcm.c
++++ b/tpcm.c
+@@ -98,17 +98,35 @@ static EFI_STATUS tpcm_get_response_blocked(void)
+     return efi_status;
+ }
+ 
++static void wide_char_to_multi_byte(CHAR16 *description, UINT8 *filename, UINT32 *filename_len)
++{
++    UINT8 *str = (UINT8 *)description;
++    UINT32 len = *filename_len;
++    UINT32 i;
++    *filename_len = 0;
++    for (i = 0; i < len; i++) {
++        if (str[i] == 0 || str[i] == '\\') {
++	    continue;
++	}
++	filename[*filename_len] = str[i];
++        (*filename_len)++;
++    }
++    filename[*filename_len] = '\0';
++}
++
+ static EFI_STATUS tpcm_fillup_hash_content(OEM_BMC_MEASURE_REQUSET *request_data, unsigned char *content,
+     CHAR16 *description)
+ {
+     UINT32 filename_len = StrLen(description) * 2 + 1;
+     UINT32 stage_base = bm_stage_base++;
++    UINT8 filename[FIRMWARE_NAME_SIZE] = {0};
+ 
+     if (filename_len > FIRMWARE_NAME_SIZE) {
+         console_print(L"the path strings is pass the size of FirmwareHashContent.uaObj!\n");
+         return EFI_INVALID_PARAMETER;
+     }
+ 
++    wide_char_to_multi_byte(description, filename, &filename_len);
+     console_print(L"start filling the hash content.\n");
+     request_data->FirmwareHashContent.uiCmdTag = TRANS(TPCM_TAG_REQ_COMMAND);
+     request_data->FirmwareHashContent.uiCmdLength = TRANS(sizeof(extern_simple_bmeasure_req_st));
+@@ -120,8 +138,7 @@ static EFI_STATUS tpcm_fillup_hash_content(OEM_BMC_MEASURE_REQUSET *request_data
+     memcpy((UINT8 *)(request_data->FirmwareHashContent.uaDigest), content, DEFAULT_HASH_SIZE);
+     request_data->FirmwareHashContent.uiObjLen = TRANS(filename_len);
+ 
+-    memcpy((UINT8 *)(request_data->FirmwareHashContent.uaObj), description, filename_len);
+-    request_data->FirmwareHashContent.uaObj[filename_len - 1] = '\0';
++    memcpy((UINT8 *)(request_data->FirmwareHashContent.uaObj), filename, filename_len);
+ 
+     return EFI_SUCCESS;
+ }
+-- 
+2.27.0
+

backport-CVE-2023-0464.patch

@@ -0,0 +1,216 @@
+From ed19b0008b5802505a6ccb05e5bac05baf90c418 Mon Sep 17 00:00:00 2001
+rom: Pauli <pauli@openssl.org>
+Date: Wed, 8 Mar 2023 15:28:20 +1100
+Subject: [PATCH] x509: excessive resource use verifying policy
+constraints
+
+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: Tomas Mraz <tomas@openssl.org>
+Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
+(Merged from https://github.com/openssl/openssl/pull/20569)
+
+---
+ Cryptlib/OpenSSL/crypto/x509v3/pcy_int.h  |  8 +++++-
+ Cryptlib/OpenSSL/crypto/x509v3/pcy_node.c | 11 +++++++--
+ Cryptlib/OpenSSL/crypto/x509v3/pcy_tree.c | 30 ++++++++++++++---------
+ 3 files changed, 35 insertions(+), 14 deletions(-)
+
+diff --git a/Cryptlib/OpenSSL/crypto/x509v3/pcy_int.h b/Cryptlib/OpenSSL/crypto/x509v3/pcy_int.h
+index b5075f9..0ed2349 100644
+--- a/Cryptlib/OpenSSL/crypto/x509v3/pcy_int.h
++++ b/Cryptlib/OpenSSL/crypto/x509v3/pcy_int.h
+@@ -161,6 +161,11 @@ struct X509_POLICY_LEVEL_st {
+ };
+ 
+ struct X509_POLICY_TREE_st {
++    /* The number of nodes in the tree */
++    size_t node_count;
++    /* The maximum number of nodes in the tree */
++    size_t node_maximum;
++
+     /* This is the tree 'level' data */
+     X509_POLICY_LEVEL *levels;
+     int nlevel;
+@@ -209,7 +214,8 @@ X509_POLICY_NODE *tree_find_sk(STACK_OF(X509_POLICY_NODE) *sk,
+ X509_POLICY_NODE *level_add_node(X509_POLICY_LEVEL *level,
+                                  const X509_POLICY_DATA *data,
+                                  X509_POLICY_NODE *parent,
+-                                 X509_POLICY_TREE *tree);
++                                 X509_POLICY_TREE *tree,
++                                 int extra_data);
+ void policy_node_free(X509_POLICY_NODE *node);
+ int policy_node_match(const X509_POLICY_LEVEL *lvl,
+                       const X509_POLICY_NODE *node, const ASN1_OBJECT *oid);
+diff --git a/Cryptlib/OpenSSL/crypto/x509v3/pcy_node.c b/Cryptlib/OpenSSL/crypto/x509v3/pcy_node.c
+index d6c9176..75b3791 100644
+--- a/Cryptlib/OpenSSL/crypto/x509v3/pcy_node.c
++++ b/Cryptlib/OpenSSL/crypto/x509v3/pcy_node.c
+@@ -111,9 +111,15 @@ X509_POLICY_NODE *level_find_node(const X509_POLICY_LEVEL *level,
+ X509_POLICY_NODE *level_add_node(X509_POLICY_LEVEL *level,
+                                  const X509_POLICY_DATA *data,
+                                  X509_POLICY_NODE *parent,
+-                                 X509_POLICY_TREE *tree)
++                                 X509_POLICY_TREE *tree,
++                                 int extra_data)
+ {
+     X509_POLICY_NODE *node;
++
++    /* Verify that the tree isn't too large. this mitigates CVE-2023-0464 */
++    if (tree->node_maximum > 0 && tree->node_count >= tree->node_maximum)
++        return NULL;
++
+     node = OPENSSL_malloc(sizeof(X509_POLICY_NODE));
+     if (!node)
+         return NULL;
+@@ -136,7 +142,7 @@ X509_POLICY_NODE *level_add_node(X509_POLICY_LEVEL *level,
+         }
+     }
+ 
+-    if (tree) {
++    if (extra_data) {
+         if (!tree->extra_data)
+             tree->extra_data = sk_X509_POLICY_DATA_new_null();
+         if (!tree->extra_data)
+@@ -145,6 +151,7 @@ X509_POLICY_NODE *level_add_node(X509_POLICY_LEVEL *level,
+             goto node_error;
+     }
+ 
++    tree->node_count++;
+     if (parent)
+         parent->nchild++;
+ 
+diff --git a/Cryptlib/OpenSSL/crypto/x509v3/pcy_tree.c b/Cryptlib/OpenSSL/crypto/x509v3/pcy_tree.c
+index 09b8691..fb9a616 100644
+--- a/Cryptlib/OpenSSL/crypto/x509v3/pcy_tree.c
++++ b/Cryptlib/OpenSSL/crypto/x509v3/pcy_tree.c
+@@ -63,6 +63,10 @@
+ 
+ #include "pcy_int.h"
+ 
++#ifndef OPENSSL_POLICY_TREE_NODES_MAX
++# define OPENSSL_POLICY_TREE_NODES_MAX 1000
++#endif
++
+ /*
+  * Enable this to print out the complete policy tree at various point during
+  * evaluation.
+@@ -225,6 +229,8 @@ static int tree_init(X509_POLICY_TREE **ptree, STACK_OF(X509) *certs,
+     if (!tree)
+         return 0;
+ 
++    /* Limit the groeth of the tree to mitigate CVE-2023-0464 */
++    tree->node_maximum = OPENSSL_POLICY_TREE_NODES_MAX;
+     tree->flags = 0;
+     tree->levels = OPENSSL_malloc(sizeof(X509_POLICY_LEVEL) * n);
+     tree->nlevel = 0;
+@@ -247,7 +253,7 @@ static int tree_init(X509_POLICY_TREE **ptree, STACK_OF(X509) *certs,
+ 
+     data = policy_data_new(NULL, OBJ_nid2obj(NID_any_policy), 0);
+ 
+-    if (!data || !level_add_node(level, data, NULL, tree))
++    if (!data || !level_add_node(level, data, NULL, tree, 1))
+         goto bad_tree;
+ 
+     for (i = n - 2; i >= 0; i--) {
+@@ -304,7 +310,8 @@ static int tree_init(X509_POLICY_TREE **ptree, STACK_OF(X509) *certs,
+ }
+ 
+ static int tree_link_matching_nodes(X509_POLICY_LEVEL *curr,
+-                                    const X509_POLICY_DATA *data)
++                                    const X509_POLICY_DATA *data,
++                                    X509_POLICY_TREE *tree)
+ {
+     X509_POLICY_LEVEL *last = curr - 1;
+     X509_POLICY_NODE *node;
+@@ -313,13 +320,13 @@ static int tree_link_matching_nodes(X509_POLICY_LEVEL *curr,
+     for (i = 0; i < sk_X509_POLICY_NODE_num(last->nodes); i++) {
+         node = sk_X509_POLICY_NODE_value(last->nodes, i);
+         if (policy_node_match(last, node, data->valid_policy)) {
+-            if (!level_add_node(curr, data, node, NULL))
++            if (!level_add_node(curr, data, node, tree, 0))
+                 return 0;
+             matched = 1;
+         }
+     }
+     if (!matched && last->anyPolicy) {
+-        if (!level_add_node(curr, data, last->anyPolicy, NULL))
++        if (!level_add_node(curr, data, last->anyPolicy, tree, 0))
+             return 0;
+     }
+     return 1;
+@@ -331,7 +338,8 @@ static int tree_link_matching_nodes(X509_POLICY_LEVEL *curr,
+  */
+ 
+ static int tree_link_nodes(X509_POLICY_LEVEL *curr,
+-                           const X509_POLICY_CACHE *cache)
++                           const X509_POLICY_CACHE *cache,
++                           X509_POLICY_TREE *tree)
+ {
+     int i;
+     X509_POLICY_DATA *data;
+@@ -352,7 +360,7 @@ static int tree_link_nodes(X509_POLICY_LEVEL *curr,
+             continue;
+ #endif
+         /* Look for matching nodes in previous level */
+-        if (!tree_link_matching_nodes(curr, data))
++        if (!tree_link_matching_nodes(curr, data, tree))
+             return 0;
+     }
+     return 1;
+@@ -382,7 +390,7 @@ static int tree_add_unmatched(X509_POLICY_LEVEL *curr,
+     /* Curr may not have anyPolicy */
+     data->qualifier_set = cache->anyPolicy->qualifier_set;
+     data->flags |= POLICY_DATA_FLAG_SHARED_QUALIFIERS;
+-    if (!level_add_node(curr, data, node, tree)) {
++    if (!level_add_node(curr, data, node, tree, 1)) {
+         policy_data_free(data);
+         return 0;
+     }
+@@ -464,7 +472,7 @@ static int tree_link_any(X509_POLICY_LEVEL *curr,
+         /* Curr may not have anyPolicy */
+         data->qualifier_set = cache->anyPolicy->qualifier_set;
+         data->flags |= POLICY_DATA_FLAG_SHARED_QUALIFIERS;
+-        if (!level_add_node(curr, data, node, tree)) {
++        if (!level_add_node(curr, data, node, tree, 1)) {
+             policy_data_free(data);
+             return 0;
+         }
+@@ -473,7 +481,7 @@ static int tree_link_any(X509_POLICY_LEVEL *curr,
+     }
+     /* Finally add link to anyPolicy */
+     if (last->anyPolicy) {
+-        if (!level_add_node(curr, cache->anyPolicy, last->anyPolicy, NULL))
++        if (!level_add_node(curr, cache->anyPolicy, last->anyPolicy, tree, 0))
+             return 0;
+     }
+     return 1;
+@@ -646,7 +654,7 @@ static int tree_calculate_user_set(X509_POLICY_TREE *tree,
+             extra->qualifier_set = anyPolicy->data->qualifier_set;
+             extra->flags = POLICY_DATA_FLAG_SHARED_QUALIFIERS
+                 | POLICY_DATA_FLAG_EXTRA_NODE;
+-            node = level_add_node(NULL, extra, anyPolicy->parent, tree);
++            node = level_add_node(NULL, extra, anyPolicy->parent, tree, 1);
+         }
+         if (!tree->user_policies) {
+             tree->user_policies = sk_X509_POLICY_NODE_new_null();
+@@ -668,7 +676,7 @@ static int tree_evaluate(X509_POLICY_TREE *tree)
+ 
+     for (i = 1; i < tree->nlevel; i++, curr++) {
+         cache = policy_cache_set(curr->cert);
+-        if (!tree_link_nodes(curr, cache))
++        if (!tree_link_nodes(curr, cache, tree))
+             return 0;
+ 
+         if (!(curr->flags & X509_V_FLAG_INHIBIT_ANY)
+-- 
+2.27.0
+

backport-CVE-2023-0465.patch

@@ -0,0 +1,56 @@
+From b013765abfa80036dc779dd0e50602c57bb3bf95 Mon Sep 17 00:00:00 2001
+From: Matt Caswell <matt@openssl.org>
+Date: Tue, 7 Mar 2023 16:52:55 +0000
+Subject: [PATCH] Ensure that EXFLAG_INVALID_POLICY is checked even in
+leaf
+ certs
+
+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: Hugo Landau <hlandau@openssl.org>
+Reviewed-by: Tomas Mraz <tomas@openssl.org>
+(Merged from https://github.com/openssl/openssl/pull/20588)
+
+Reference:https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=b013765abfa80036dc779dd0e50602c57bb3bf95
+Conflict: Context conflict
+---
+ Cryptlib/OpenSSL/crypto/x509/x509_vfy.c | 11 +++++++++--
+ 1 file changed, 9 insertions(+), 2 deletions(-)
+
+diff --git a/Cryptlib/OpenSSL/crypto/x509/x509_vfy.c b/Cryptlib/OpenSSL/crypto/x509/x509_vfy.c
+index 96f306b..a6878fe 100644
+--- a/Cryptlib/OpenSSL/crypto/x509/x509_vfy.c
++++ b/Cryptlib/OpenSSL/crypto/x509/x509_vfy.c
+@@ -1768,16 +1768,23 @@ static int check_policy(X509_STORE_CTX *ctx)
+          * Locate certificates with bad extensions and notify callback.
+          */
+         X509 *x;
+-        int i;
+-        for (i = 1; i < sk_X509_num(ctx->chain); i++) {
++        int i, cbcalled = 0;
++        for (i = 0; i < sk_X509_num(ctx->chain); i++) {
+             x = sk_X509_value(ctx->chain, i);
+             if (!(x->ex_flags & EXFLAG_INVALID_POLICY))
+                 continue;
++	    cbcalled = 1;
+             ctx->current_cert = x;
+             ctx->error = X509_V_ERR_INVALID_POLICY_EXTENSION;
+             if (!ctx->verify_cb(0, ctx))
+                 return 0;
+         }
++        if (!cbcalled) {
++            /* Should not be able to get here */
++            X509err(X509_F_CHECK_POLICY, ERR_R_INTERNAL_ERROR);
++            return 0;
++        }
++        /* The callback ignored the error so we return success */
+         return 1;
+     }
+     if (ret == -2) {
+-- 
+2.33.0
+

backport-CVE-2023-2650.patch

@@ -0,0 +1,67 @@
+From 423a2bc737a908ad0c77bda470b2b59dc879936b Mon Sep 17 00:00:00 2001
+From: Richard Levitte <levitte@openssl.org>
+Date: Fri, 12 May 2023 10:00:13 +0200
+Subject: [PATCH] Restrict the size of OBJECT IDENTIFIERs that OBJ_obj2txt will
+ translate
+
+Reference:https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=423a2bc737a908ad0c77bda470b2b59dc879936b
+Conflict:NA
+
+OBJ_obj2txt() would translate any size OBJECT IDENTIFIER to canonical
+numeric text form.  For gigantic sub-identifiers, this would take a very
+long time, the time complexity being O(n^2) where n is the size of that
+sub-identifier.
+
+To mitigate this, a restriction on the size that OBJ_obj2txt() will
+translate to canonical numeric text form is added, based on RFC 2578
+(STD 58), which says this:
+
+> 3.5. OBJECT IDENTIFIER values
+>
+> An OBJECT IDENTIFIER value is an ordered list of non-negative numbers.
+> For the SMIv2, each number in the list is referred to as a sub-identifier,
+> there are at most 128 sub-identifiers in a value, and each sub-identifier
+> has a maximum value of 2^32-1 (4294967295 decimal).
+
+Fixes otc/security#96
+Fixes CVE-2023-2650
+
+Reviewed-by: Matt Caswell <matt@openssl.org>
+Reviewed-by: Tomas Mraz <tomas@openssl.org>
+---
+ crypto/objects/obj_dat.c | 19 +++++++++++++++++++
+ 1 files changed, 50 insertions(+)
+
+diff --git a/crypto/objects/obj_dat.c b/crypto/objects/obj_dat.c
+index 01cde00e98..c0e55197a0 100644
+--- a/Cryptlib/OpenSSL/crypto/objects/obj_dat.c
++++ b/Cryptlib/OpenSSL/crypto/objects/obj_dat.c
+@@ -443,6 +443,25 @@ int OBJ_obj2txt(char *buf, int buf_len, const ASN1_OBJECT *a, int no_name)
+     first = 1;
+     bl = NULL;
+ 
++    /*
++     * RFC 2578 (STD 58) says this about OBJECT IDENTIFIERs:
++     *
++     * > 3.5. OBJECT IDENTIFIER values
++     * >
++     * > An OBJECT IDENTIFIER value is an ordered list of non-negative
++     * > numbers. For the SMIv2, each number in the list is referred to as a
++     * > sub-identifier, there are at most 128 sub-identifiers in a value,
++     * > and each sub-identifier has a maximum value of 2^32-1 (4294967295
++     * > decimal).
++     *
++     * So a legitimate OID according to this RFC is at most (32 * 128 / 7),
++     * i.e. 586 bytes long.
++     *
++     * Ref: https://datatracker.ietf.org/doc/html/rfc2578#section-3.5
++     */
++    if (len > 586)
++        goto err;
++
+     while (len > 0) {
+         l = 0;
+         use_bn = 0;
+-- 
+2.34.1
+

backport-CVE-2023-3446.patch

@@ -0,0 +1,77 @@
+From 8780a896543a654e757db1b9396383f9d8095528 Mon Sep 17 00:00:00 2001
+From: Matt Caswell <matt@openssl.org>
+Date: Thu, 6 Jul 2023 16:36:35 +0100
+Subject: [PATCH] Fix DH_check() excessive time with over sized modulus
+
+The DH_check() function checks numerous aspects of the key or parameters
+that have been supplied. Some of those checks use the supplied modulus
+value even if it is excessively large.
+
+There is already a maximum DH modulus size (10,000 bits) over which
+OpenSSL will not generate or derive keys. DH_check() will however still
+perform various tests for validity on such a large modulus. We introduce
+a
+new maximum (32,768) over which DH_check() will just fail.
+
+An application that calls DH_check() and supplies a key or parameters
+obtained from an untrusted source could be vulnerable to a Denial of
+Service attack.
+
+The function DH_check() is itself called by a number of other OpenSSL
+functions. An application calling any of those other functions may
+similarly be affected. The other functions affected by this are
+DH_check_ex() and EVP_PKEY_param_check().
+
+CVE-2023-3446
+
+Reviewed-by: Paul Dale <pauli@openssl.org>
+Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
+Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
+Reviewed-by: Tomas Mraz <tomas@openssl.org>
+(Merged from https://github.com/openssl/openssl/pull/21452)
+---
+ Cryptlib/Include/openssl/dh.h         | 5 +++++
+ Cryptlib/OpenSSL/crypto/dh/dh_check.c | 4 ++++
+ 2 files changed, 9 insertions(+)
+
+diff --git a/Cryptlib/Include/openssl/dh.h b/Cryptlib/Include/openssl/dh.h
+index 6488879..06142df 100644
+--- a/Cryptlib/Include/openssl/dh.h
++++ b/Cryptlib/Include/openssl/dh.h
+@@ -77,6 +77,10 @@
+ #  define OPENSSL_DH_MAX_MODULUS_BITS    10000
+ # endif
+ 
++# ifndef OPENSSL_DH_CHECK_MAX_MODULUS_BITS
++#  define OPENSSL_DH_CHECK_MAX_MODULUS_BITS 32768
++# endif
++
+ # define DH_FLAG_CACHE_MONT_P     0x01
+ 
+ /*
+@@ -356,6 +360,7 @@ void ERR_load_DH_strings(void);
+ # define DH_F_COMPUTE_KEY                                 102
+ # define DH_F_DHPARAMS_PRINT_FP                           101
+ # define DH_F_DH_BUILTIN_GENPARAMS                        106
++# define DH_F_DH_CHECK                                    126
+ # define DH_F_DH_CMS_DECRYPT                              117
+ # define DH_F_DH_CMS_SET_PEERKEY                          118
+ # define DH_F_DH_CMS_SET_SHARED_INFO                      119
+diff --git a/Cryptlib/OpenSSL/crypto/dh/dh_check.c b/Cryptlib/OpenSSL/crypto/dh/dh_check.c
+index 9f3b174..9c62da4 100644
+--- a/Cryptlib/OpenSSL/crypto/dh/dh_check.c
++++ b/Cryptlib/OpenSSL/crypto/dh/dh_check.c
+@@ -78,6 +78,10 @@ int DH_check(const DH *dh, int *ret)
+     BN_ULONG l;
+     BIGNUM *t1 = NULL, *t2 = NULL;
+ 
++    /* Don't do any check at all with an excessively large modulus */
++    if (BN_num_bits(dh->p) > OPENSSL_DH_CHECK_MAX_MODULUS_BITS) {
++        return 0;
++    }
+     *ret = 0;
+     ctx = BN_CTX_new();
+     if (ctx == NULL)
+-- 
+2.27.0
+

backport-CVE-2023-3817.patch

@@ -0,0 +1,58 @@
+From 91ddeba0f2269b017dc06c46c993a788974b1aa5 Mon Sep 17 00:00:00 2001
+From: Tomas Mraz <tomas@openssl.org>
+Date: Fri, 21 Jul 2023 11:39:41 +0200
+Subject: [PATCH 1/2] DH_check(): Do not try checking q properties if it is
+ obviously invalid
+
+If  |q| >= |p| then the q value is obviously wrong as q
+is supposed to be a prime divisor of p-1.
+
+We check if p is overly large so this added test implies that
+q is not large either when performing subsequent tests using that
+q value.
+
+Otherwise if it is too large these additional checks of the q value
+such as the primality test can then trigger DoS by doing overly long
+computations.
+
+Fixes CVE-2023-3817
+
+Reviewed-by: Paul Dale <pauli@openssl.org>
+Reviewed-by: Matt Caswell <matt@openssl.org>
+(Merged from https://github.com/openssl/openssl/pull/21551)
+---
+ crypto/dh/dh_check.c | 11 +++++++++--
+ 1 file changed, 9 insertions(+), 2 deletions(-)
+
+diff --git a/crypto/dh/dh_check.c b/crypto/dh/dh_check.c
+index 2001d2e7cb..9ae96991eb 100644
+--- a/Cryptlib/OpenSSL/crypto/dh/dh_check.c
++++ b/Cryptlib/OpenSSL/crypto/dh/dh_check.c
+@@ -97,7 +97,7 @@ int DH_check_ex(const DH *dh)
+ 
+ int DH_check(const DH *dh, int *ret)
+ {
+-    int ok = 0;
++    int ok = 0, q_good = 0;
+     BN_CTX *ctx = NULL;
+     BN_ULONG l;
+     BIGNUM *t1 = NULL, *t2 = NULL;
+@@ -120,7 +120,14 @@ int DH_check(const DH *dh, int *ret)
+     if (t2 == NULL)
+         goto err;
+ 
+-    if (dh->q) {
++    if (dh->q != NULL) {
++        if (BN_ucmp(dh->p, dh->q) > 0)
++            q_good = 1;
++        else
++            *ret |= DH_CHECK_INVALID_Q_VALUE;
++    }
++
++    if (q_good) {
+         if (BN_cmp(dh->g, BN_value_one()) <= 0)
+             *ret |= DH_NOT_SUITABLE_GENERATOR;
+         else if (BN_cmp(dh->g, dh->p) >= 0)
+-- 
+2.33.0
+

backport-CVE-2023-40547-avoid-incorrectly-trusting-HTTP-heade.patch

@@ -0,0 +1,45 @@
+From 0226b56513b2b8bd5fd281bce77c40c9bf07c66d Mon Sep 17 00:00:00 2001
+From: Peter Jones <pjones@redhat.com>
+Date: Wed, 2 Aug 2023 14:19:31 -0400
+Subject: [PATCH] CVE-2023-40547 - avoid incorrectly trusting HTTP headers
+
+When retrieving files via HTTP or related protocols, shim attempts to
+allocate a buffer to store the received data.  Unfortunately, this means
+getting the size from an HTTP header, which can be manipulated to
+specify a size that's smaller than the received data.  In this case, the
+code accidentally uses the header for the allocation but the protocol
+metadata to copy it from the rx buffer, resulting in an out-of-bounds
+write.
+
+This patch adds an additional check to test that the rx buffer is not
+larger than the allocation.
+
+Resolves: CVE-2023-40547
+Reported-by: Bill Demirkapi, Microsoft Security Response Center
+Signed-off-by: Peter Jones <pjones@redhat.com>
+---
+ httpboot.c | 8 +++++++-
+ 1 file changed, 7 insertions(+), 1 deletion(-)
+
+diff --git a/httpboot.c b/httpboot.c
+index dfa493b..b34dd49 100644
+--- a/httpboot.c
++++ b/httpboot.c
+@@ -578,7 +578,13 @@ receive_http_response(EFI_HTTP_PROTOCOL *http, VOID **buffer, UINT64 *buf_size)
+ 	}
+ 
+ 	if (*buf_size == 0) {
+-		perror(L"Failed to get Content-Lenght\n");
++		perror(L"Failed to get Content-Length\n");
++		goto error;
++	}
++
++	if (*buf_size < rx_message.BodyLength) {
++		efi_status = EFI_BAD_BUFFER_SIZE;
++		perror(L"Invalid Content-Length\n");
+ 		goto error;
+ 	}
+ 
+-- 
+2.33.0
+

backport-CVE-2023-40551-pe-relocate-Fix-bounds-check-for-MZ-b.patch

@@ -0,0 +1,81 @@
+From 945f88af2301bb4deec66eb16cd47136970ab2f2 Mon Sep 17 00:00:00 2001
+From: jinlun <jinlun@huawei.com>
+Date: Tue, 30 Jan 2024 10:20:28 +0800
+Subject: [PATCH] CVE-2023-40551: pe-relocate: Fix bounds check for MZ binaries
+
+In read_header(), we attempt to parse the PE binary headers.  In doing
+so, if there is an MZ (i.e. MS-DOS) header, we locate the PE header by
+finding the offset in that header.  Unfortunately that is not correctly
+bounds checked, and carefully chosen values can cause an out-of-bounds
+ready beyond the end of the loaded binary.
+
+Unfortunately the trivial fix (bounds check that value) also makes it
+clear that the way we were determining if an image is loadable on this
+platform and distinguishing between PE32 and PE32+ binaries has the
+exact same issue going on, and so the fix includes reworking that logic
+to correctly bounds check all of those tests as well.
+h
+It's not currently known if this is actually exploitable beyond creating
+a denial of service, and an attacker who is in a position to use it for
+a denial of service attack must already be able to do so.
+
+Resolves: CVE-2023-40551
+Reported-by: gkirkpatrick@google.com
+Signed-off-by: Peter Jones <pjones@redhat.com>
+---
+ shim.c | 26 +++++++++++++++++++++++---
+ 1 file changed, 23 insertions(+), 3 deletions(-)
+
+diff --git a/shim.c b/shim.c
+index 2c3dbf3..8bfa652 100644
+--- a/shim.c
++++ b/shim.c
+@@ -161,7 +161,7 @@ static int
+ image_is_64_bit(EFI_IMAGE_OPTIONAL_HEADER_UNION *PEHdr)
+ {
+ 	/* .Magic is the same offset in all cases */
+-	if (PEHdr->Pe32Plus.OptionalHeader.Magic
++	if (PEHdr->Pe32.OptionalHeader.Magic
+ 			== EFI_IMAGE_NT_OPTIONAL_HDR64_MAGIC)
+ 		return 1;
+ 	return 0;
+@@ -1095,14 +1095,34 @@ static EFI_STATUS read_header(void *data, unsigned int datasize,
+ 	EFI_IMAGE_OPTIONAL_HEADER_UNION *PEHdr = data;
+ 	unsigned long HeaderWithoutDataDir, SectionHeaderOffset, OptHeaderSize;
+ 	unsigned long FileAlignment = 0;
++	size_t dos_sz = 0;
+ 
+-	if (datasize < sizeof (PEHdr->Pe32)) {
++	if (datasize < sizeof (*DosHdr)) {
+ 		perror(L"Invalid image\n");
+ 		return EFI_UNSUPPORTED;
+ 	}
+ 
+-	if (DosHdr->e_magic == EFI_IMAGE_DOS_SIGNATURE)
++	if (DosHdr->e_magic == EFI_IMAGE_DOS_SIGNATURE) {
++		if (DosHdr->e_lfanew < sizeof (*DosHdr) ||
++		    DosHdr->e_lfanew > datasize - 4) {
++		perror(L"Invalid image\n");
++		return EFI_UNSUPPORTED;
++		}
++
++		dos_sz = DosHdr->e_lfanew;
+ 		PEHdr = (EFI_IMAGE_OPTIONAL_HEADER_UNION *)((char *)data + DosHdr->e_lfanew);
++	}
++
++	if (datasize - dos_sz < sizeof (PEHdr->Pe32)) {
++		perror(L"Invalid image\n");
++		return EFI_UNSUPPORTED;
++	}
++
++	if (image_is_64_bit(PEHdr) &&
++	    (datasize - dos_sz < sizeof (PEHdr->Pe32Plus))) {
++		perror(L"Invalid image\n");
++		return EFI_UNSUPPORTED;
++	}
+ 
+ 	if (!image_is_loadable(PEHdr)) {
+ 		perror(L"Platform does not support this image\n");
+-- 
+2.33.0
+

backport-Fix-the-issue-that-the-gBS-LoadImage-pointer-was-emp.patch

@@ -0,0 +1,39 @@
+From 712097206702f26e96be3f7ba79eb52d00e1f658 Mon Sep 17 00:00:00 2001
+From: jinlun <869793317@qq.com>
+Date: Sat, 2 Nov 2024 17:21:22 +0800
+Subject: [PATCH] Fix the issue that the gBS->LoadImage pointer was empty.
+
+The interface shouldn't be replaced at the shim_fini
+ stage When the vendor certificate doesn't exist.
+
+Signed-off-by: jinlun <869793317@qq.com>
+Signed-off-by: xuce <xuce10@h-partners.com>
+---
+ shim.c | 11 ++++++-----
+ 1 file changed, 6 insertions(+), 5 deletions(-)
+
+diff --git a/shim.c b/shim.c
+index 547b052..aa74610 100644
+--- a/shim.c
++++ b/shim.c
+@@ -1651,11 +1651,12 @@ shim_fini(void)
+ 	uninstall_shim_protocols();
+ 
+ 	if (secure_mode()) {
+-
+-		/*
+-		 * Remove our hooks from system services.
+-		 */
+-		unhook_system_services();
++		if (vendor_cert_size || vendor_dbx_size) {
++			/*
++			* Remove our hooks from system services.
++			*/
++			unhook_system_services();
++		}
+ 	}
+ 
+ 	unhook_exit();
+-- 
+2.33.0
+

shim.spec

@@ -22,7 +22,7 @@
 
 Name:		shim
 Version:	15
-Release:        31
+Release:        36
 Summary:	First-stage UEFI bootloader
 ExclusiveArch:  x86_64 aarch64
 License:	BSD
@@ -54,11 +54,20 @@ Patch19:        backport-CVE-2021-23841.patch
 Patch20:        backport-CVE-2022-0778.patch
 Patch21:        backport-CVE-2021-3712.patch
 Patch22:        backport-CVE-2023-0286.patch
+Patch23:        backport-CVE-2023-0464.patch
+Patch24:        backport-CVE-2023-3817.patch
+Patch25:        backport-CVE-2023-40551-pe-relocate-Fix-bounds-check-for-MZ-b.patch
+Patch26:        backport-CVE-2023-40547-avoid-incorrectly-trusting-HTTP-heade.patch
+Patch27:        backport-CVE-2023-3446.patch
+Patch28:        backport-CVE-2023-0465.patch
+Patch29:        backport-CVE-2023-2650.patch
+Patch30:        backport-Fix-the-issue-that-the-gBS-LoadImage-pointer-was-emp.patch
 
 # Feature
 Patch9000:	Feature-add-tpcm-support-with-ipmi-channel.patch
 Patch9001:      fix-the-bug-for-fb-and-mok-do-some-clean-code.patch
 Patch9002:      Feature-add-control-switch-to-optimized-exception-handling.patch
+Patch9003:      Feature-Convert-file-name-from-wide-char-to-narrow-char.patch
 
 BuildRequires:	elfutils-libelf-devel openssl-devel openssl git pesign gnu-efi gnu-efi-devel gcc
 Requires:       dbxtool efi-filesystem mokutil
@@ -157,6 +166,21 @@ cd ..
 /usr/src/debug/%{name}-%{version}-%{release}/*
 
 %changelog
+* Tue Feb 11 2025 fuanan <fuanan3@h-partners.com> - 15-36
+- fix the issue that the gBS->LoadImage pointer was empty.
+
+* Wed Feb 28 2024 zhengxiaoxiao <zhengxiaoxiao2@huawei.com> - 15-35
+- fix CVE-2023-3446 CVE-2023-0465 CVE-2023-2650
+
+* Tue Jan 30 2024 jinlun <jinlun@huawei.com> - 15-34
+- fix CVE-2023-40547 CVE-2023-40551
+
+* Sat Oct 14 2023 ExtinctFire <shenyining_00@126.com> - 15-33
+- fix CVE-2023-0464 CVE-2023-3817
+
+* Thu Jul 13 2023 jinlun <jinlun@huawei.com> - 15-32
+- Convert file name from wide char to narrow char
+
 * Wed Jun 14 2023 jinlun <jinlun@huawei.com> - 15-31
 - add control switch to optimized exception handling.