BaseTools/Conf/tools_def.template | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

 pass -fno-stack-protector to all gcc toolchains
 The upstream build rules inexplicably pass -fno-stack-protector only
 when building for i386 and amd64.  Add this essential argument to the
 generic rules for gcc 4.8 and later.
Last-Updated: 2023-07-21

BaseTools/Source/C/GNUmakefile | 1 0 + 1 - 0 !
1 file changed, 1 deletion(-)

 do not attempt to compile removed brotlicompress source
 BrotliCompress is not currently used, and including an embedded
 copy of its source could cause false-positives when scanning for
 security issues. This code is stripped from our orig.tar (at the request
 of the Ubuntu security team), so we also need to disable the build.

BaseTools/Conf/tools_def.template | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

 explicitly target generic x86-64 abi
 The system compiler may be configured to target a higher x86-64 psABI by
 default, so explicitly target the generic psABI to retain compatibility
 with older machine types.

OvmfPkg/Include/Library/PlatformInitLib.h | 1 1 + 0 - 0 !
OvmfPkg/Library/PlatformInitLib/MemDetect.c | 9 6 + 3 - 0 !
2 files changed, 7 insertions(+), 3 deletions(-)

 [patch] ovmfpkg: use user-specified opt/ovmf/x-pcimmio64mb value
 unconditionally

Prior to this change, OVMF considers opt/ovmf/X-PciMmio64Mb the
minimum aperture size, allowing us to force the window to be larger
but not smaller than what PlatformDynamicMmioWindow calculates.

Adjust OVMF so that a smaller value for the aperture is honored.

Context:
Due to an inefficiency in the way older host kernels manage
pfnmaps for guest VM memory ranges [0], guests with large-BAR
GPUs passed-through have a very long (multiple minutes) initialization
time when the MMIO window advertised by OVMF is sufficiently sized for
the passed-through BARs (i.e., the correct OVMF behavior). However, on
older distro series such as Ubuntu Jammy, users have benefited from fast
guest boot times when OVMF advertised an MMIO window that was too small
to accommodate the full BAR, since this resulted in the long PCI initialization
process being skipped (and retried later, if pci=realloc pci=nocrs were set).

While the root cause is being fully addressed in the upstream kernel [1],
the solution relies on huge pfnmap support, which is a substantial series
with many ABI changes that is unlikely to land in many LTS and legacy distro kernels,
including those of Ubuntu Noble. As a result, the only kernel improvement
supported on those kernels is this patch [2], which reduces the extra boot
time by about half. Unfortunately, that boot time is still an average of
1-3 minutes longer per-VM-boot than what can be achieved when the host is
running a version of OVMF without PlatformDynamicMmioWindow (PDMW) support
(introduced in [3])

Since there is no way to force the use of the classic MMIO window size[4]
in any version of OVMF after [3], and since we have a use case for such
functionality on legacy distro kernels that would yield significant,
recurring compute time savings across all impacted VMs, this change to
this knob's behavior seems appropriate.

[0]: https://lore.kernel.org/all/CAHTA-uYp07FgM6T1OZQKqAdSA5JrZo0ReNEyZgQZub4mDRrV5w@mail.gmail.com/
[1]: https://lore.kernel.org/all/20250205231728.2527186-1-alex.williamson@redhat.com/
[2]: https://lore.kernel.org/all/20250111210652.402845-1-alex.williamson@redhat.com/
[3]: ecb778d
[4]: https://edk2.groups.io/g/devel/topic/109651206?p=Created,,,20,1,0,0

Signed-off-by: Mitchell Augustin <mitchell.augustin@canonical.com>

Bug-Ubuntu: https://launchpad.net/bugs/2101903

NetworkPkg/IScsiDxe/IScsiProto.c | 10 8 + 2 - 0 !
1 file changed, 8 insertions(+), 2 deletions(-)

 [patch] networkpkg/iscsidxe:fix for remote memory exposure in iscsi
 bz4206

Used SafeUint32Add to calculate and validate OutTransferLength with
boundary check in IScsiOnR2TRcvd to avoid integer overflow

Signed-off-by: Madhavan <madavtechy@gmail.com>

OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c | 63 63 + 0 - 0 !
OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf | 2 2 + 0 - 0 !
2 files changed, 65 insertions(+)

 [patch] ovmfpkg/x64: add opt/org.tianocore/uninstallmemattrprotocol
 support

Add support for opt/org.tianocore/UninstallMemAttrProtocol, to allow
turning off EFI_MEMORY_ATTRIBUTE_PROTOCOL, simliar to ArmVirtPkg.

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>

OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.c | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

 [patch] ovmfpkg/qemukernelloaderfsdxe: fix allocation failure check

SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.c | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

 [patch 1/4] securitypkg: out of bound read in hashpeimagebytype()

In HashPeImageByType(), the hash of PE/COFF image is calculated.
This function may get untrusted input.

Inside this function, the following code verifies the loaded image has
the correct format, by reading the second byte of the buffer.

```c
  if ((*(AuthData + 1) & TWO_BYTE_ENCODE) != TWO_BYTE_ENCODE) {
  	...
  }
```

The input image is not trusted and that may not have the second byte to
read. So this poses an out of bound read error.

With below fix we are assuring that we don't do out of bound read. i.e,
we make sure that AuthDataSize is greater than 1.

```c
  if (AuthDataSize > 1
      && (*(AuthData + 1) & TWO_BYTE_ENCODE) != TWO_BYTE_ENCODE){
    ...
  }
```

AuthDataSize size is verified before reading the second byte.
So if AuthDataSize is less than 2, the second byte will not be read, and
the out of bound read situation won't occur.

Tested the patch on real platform with and without TPM connected and
verified image is booting fine.

Authored-by: Raj AlwinX Selvaraj <Alw...@intel.com>
Signed-off-by: Doug Flick <DougFlick@microsoft.com>

SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.c | 37 19 + 18 - 0 !
1 file changed, 19 insertions(+), 18 deletions(-)

 [patch 2/4] securitypkg: improving hashpeimagebytype () logic

Namely:

(1) The TWO_BYTE_ENCODE check is independent of Index. If it evalutes
    to TRUE for Index==0, then it will evaluate to TRUE for all other
    Index values as well. As a result, the (Index == HASHALG_MAX)
    condition will fire after the loop, and we'll return
    EFI_UNSUPPORTED.

    While this is correct, functionally speaking, it is wasteful to
    keep re-checking TWO_BYTE_ENCODE in the loop body. The check
    should be made at the top of the function, and EFI_UNSUPPORTED
    should be returned at once, if appropriate.

(2) If the hash algorithm selected by Index has such a large OID that
    the OID comparison cannot even be performed (because AuthDataSize
    is not large enough for containing the OID in question, starting
    at offset 32), then the function returns EFI_UNSUPPORTED at once.

    This is bogus; this case should simply be treated as an OID
    mismatch, and the loop should advance to the next Index value /
    hash algorithm candidate. A remaining hash algo may have a shorter
    OID and yield an OID match.

Signed-off-by: Doug Flick <DougFlick@microsoft.com>

SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigImpl.c | 37 21 + 16 - 0 !
1 file changed, 21 insertions(+), 16 deletions(-)

 [patch 3/4] securitypkg: improving
 SecureBootConfigImpl:HashPeImageByType () logic

Namely:

(1) The TWO_BYTE_ENCODE check is independent of Index. If it evalutes
    to TRUE for Index==0, then it will evaluate to TRUE for all other
    Index values as well. As a result, the (Index == HASHALG_MAX)
    condition will fire after the loop, and we'll return
    EFI_UNSUPPORTED.

    While this is correct, functionally speaking, it is wasteful to
    keep re-checking TWO_BYTE_ENCODE in the loop body. The check
    should be made at the top of the function, and EFI_UNSUPPORTED
    should be returned at once, if appropriate.

(2) If the hash algorithm selected by Index has such a large OID that
    the OID comparison cannot even be performed (because AuthDataSize
    is not large enough for containing the OID in question, starting
    at offset 32), then the function returns EFI_UNSUPPORTED at once.

    This is bogus; this case should simply be treated as an OID
    mismatch, and the loop should advance to the next Index value /
    hash algorithm candidate. A remaining hash algo may have a shorter
    OID and yield an OID match.

Signed-off-by: Doug Flick <DougFlick@microsoft.com>

SecurityPkg/SecurityFixes.yaml | 15 15 + 0 - 0 !
1 file changed, 15 insertions(+)

 [patch 4/4] securitypkg: update securityfixes.yaml for cve-2024-38797

This commit updates the SecurityFixes.yaml file to include
information about the CVE-2024-38797 vulnerability.

Signed-off-by: Doug Flick <DougFlick@microsoft.com>

CryptoPkg/Library/OpensslLib/openssl/crypto/bn/bn_exp.c | 21 15 + 6 - 0 !
CryptoPkg/Library/OpensslLib/openssl/crypto/ec/ec_lib.c | 7 4 + 3 - 0 !
CryptoPkg/Library/OpensslLib/openssl/include/crypto/bn.h | 3 3 + 0 - 0 !
3 files changed, 22 insertions(+), 9 deletions(-)

 [patch] fix timing side-channel in ecdsa signature computation

There is a timing signal of around 300 nanoseconds when the top word of
the inverted ECDSA nonce value is zero. This can happen with significant
probability only for some of the supported elliptic curves. In particular
the NIST P-521 curve is affected. To be able to measure this leak, the
attacker process must either be located in the same physical computer or
must have a very fast network connection with low latency.

Attacks on ECDSA nonce are also known as Minerva attack.

Fixes CVE-2024-13176

NetworkPkg/IScsiDxe/IScsiProto.c | 29 24 + 5 - 0 !
1 file changed, 24 insertions(+), 5 deletions(-)

 [patch] networkpkg/iscsidxe:fix for out of bound memory access for
 bz4207 (CVE-2024-38805)

In IScsiBuildKeyValueList, check if we have any data left (Len > 0) before advancing the Data pointer and reducing Len.
Avoids wrapping Len. Also Used SafeUint32SubSafeUint32Sub call to reduce the Len .

Signed-off-by: santhosh kumar V <santhoshkumarv@ami.com>

UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmiEntry.nasm | 6 5 + 1 - 0 !
1 file changed, 5 insertions(+), 1 deletion(-)

 [patch] ueficpupkg/pismmcpudxesmm: safe handling of idt register on
 SMM entry

Mitigates CVE-2025-3770

Do not assume that IDT.limit is loaded with a zero value upon SMM entry.
Delay enabling Machine Check Exceptions in SMM until after the SMM IDT
has been reloaded.

Signed-off-by: John Mathews <john.mathews@intel.com>