Debian Patches

Status for edk2/2025.02-8

Patch Description Author Forwarded Bugs Origin Last update
no-stack-protector-all-archs.diff 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.		 Steve Langasek <steve.langasek@ubuntu.com> no
brotlicompress-disable.diff 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.		 dann frazier <dannf@debian.org> not-needed 2023-03-09
x64-baseline-abi.patch 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.		 dann frazier <dannf@debian.org> yes 2024-11-24
0001-OvmfPkg-Use-user-specified-opt-ovmf-X-PciMmio64Mb-va.patch [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




diff --git a/OvmfPkg/Include/Library/PlatformInitLib.h b/OvmfPkg/Include/Library/PlatformInitLib.h
index 57b18b94d9..ce5af42e09 100644		 Mitchell Augustin <mitchell.augustin@canonical.com> no 2025-03-15
0001-NetworkPkg-IScsiDxe-Fix-for-Remote-Memory-Exposure-i.patch [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



diff --git a/NetworkPkg/IScsiDxe/IScsiProto.c b/NetworkPkg/IScsiDxe/IScsiProto.c
index ef587649a0..fb48e6304d 100644		 Madhavan <madavtechy@gmail.com> yes debian upstream https://github.com/tianocore/edk2/commit/17cdc512f02a2dfd1b9e24133da56fdda099abda 2025-03-14
OvmfPkg-X64-add-opt-org.tianocore-UninstallMemAttrPr.patch [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.		 Gerd Hoffmann <kraxel@redhat.com> no debian https://github.com/tianocore/edk2/pull/10667/commits/aa7f29a9e92b9e6f8b2e56bacaef6c96b8dc80ed 2025-01-16
0001-OvmfPkg-QemuKernelLoaderFsDxe-fix-allocation-failure.patch [PATCH] OvmfPkg/QemuKernelLoaderFsDxe: fix allocation failure check Gerd Hoffmann <kraxel@redhat.com> yes debian upstream https://github.com/tianocore/edk2/pull/10971 2025-04-16
0001-SecurityPkg-Out-of-bound-read-in-HashPeImageByType.patch [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.



diff --git a/SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.c b/SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.c
index b05da19c2b..2afa2c93d9 100644		 Doug Flick <dougflick@microsoft.com> yes debian upstream https://github.com/tianocore/edk2/commit/5f08635ee7c176f78f788aa6528b43f18536a80b 2024-10-03
0002-SecurityPkg-Improving-HashPeImageByType-logic.patch [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.



diff --git a/SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.c b/SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.c
index 2afa2c93d9..2eca39d563 100644		 Doug Flick <dougflick@microsoft.com> yes debian upstream https://github.com/tianocore/edk2/commit/b90693965b6b1566bcac4652ad1bb436e1bb461f 2024-10-03
0003-SecurityPkg-Improving-SecureBootConfigImpl-HashPeIma.patch [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.



diff --git a/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigImpl.c b/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigImpl.c
index d4dc4e1402..d262904c31 100644		 Doug Flick <dougflick@microsoft.com> yes debian upstream https://github.com/tianocore/edk2/commit/025ab811fb2afac6b4036b0fc2fa46d0b04d1c80 2025-01-17
0004-SecurityPkg-Update-SecurityFixes.yaml-for-CVE-2024-3.patch [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.



diff --git a/SecurityPkg/SecurityFixes.yaml b/SecurityPkg/SecurityFixes.yaml
index b4006b42b8..06b597a43e 100644		 Doug Flick <dougflick@microsoft.com> yes debian upstream https://github.com/tianocore/edk2/commit/d79d8d6a8dc3b7324b167031c89400390261acf3 2025-04-07

All known versions for source package 'edk2'

Links