EDK II OvmfPkg (X86QemuLoadImageLib, QemuLoadKernelImage direct-boot path): With Secure Boot on, a kernel

UnscoredCVE-2025-2296Firmware, BMC & network fabricGHSA-6pp6-cm5h-86g5curated

Impact

With Secure Boot on, a kernel whose signature is not in the allowed database is correctly rejected by image verification - and then loaded anyway, because the code falls back to the legacy loader. The guest boots an unsigned kernel while reporting that Secure Boot is enforcing. Any tenant-isolation or attestation story that rests on guest Secure Boot in a QEMU/KVM GPU environment is simply not true on affected OVMF builds.

Who can reach it

Whoever controls the kernel image or the direct-boot command line for the VM - a tenant with access to their own instance's boot configuration, or an attacker who has compromised the image pipeline. Requires the VM to use QEMU direct kernel boot rather than a normal bootloader.

What to do

Hypervisor-side firmware package update (edk2/OVMF), not a server BIOS flash - update the ovmf/edk2 build on your hosts and restart guests onto the new firmware; no host reboot needed. Config workaround: stop using QEMU direct kernel boot for guests that rely on Secure Boot, and boot through a signed shim/bootloader from a virtual disk instead.

References

https://nvd.nist.gov/vuln/detail/CVE-2025-2296 https://github.com/tianocore/edk2/security/advisories/GHSA-6pp6-cm5h-86g5

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.