Buffer Overflow in EDK II Network Package
Buffer Overflow in EDK II Network Package
The Ubuntu edk2 UEFI firmware packages accidentally allowed the UEFI Shell to be accessed in Secure Boot environments, possibly allowing bypass of Secure Boot constraints. Versions 2024.05-2ubuntu0.3 and 2024.02-2ubuntu0.3 disable the Shell. Some previous versions inserted a secure-boot-based decision to continue running inside the Shell itself, which is believed to be sufficient to enforce Secure Boot restrictions. This is an additional repair on top of the incomplete fix for CVE-2023-48733.
Last updated 25 August 2025
EDK2 is susceptible to a vulnerability in the Tcg2MeasurePeImage() function, allowing a user to trigger a heap buffer overflow via a local network. Successful exploitation of this vulnerability may result in a compromise of confidentiality, integrity, and/or availability.
EDK2 is susceptible to a vulnerability in the Tcg2MeasureGptTable() function, allowing a user to trigger a heap buffer overflow via a local network. Successful exploitation of this vulnerability may result in a compromise of confidentiality, integrity, and/or availability.
Bounds checking in Tianocompress before November 7, 2017 may allow an authenticated user to potentially enable an escalation of privilege via local access.
Integer truncation in EDK II may allow an authenticated user to potentially enable escalation of privilege via local access.
Last updated 25 August 2025
AuthenticodeVerify() calls OpenSSLs d2iPKCS7() API to parse asn encoded signed authenticode pkcs#7 data. when this successfully returns, a type check is done by calling PKCS7typeissigned() and then Pkcs7->d.sign->contents->type is used. It is possible to construct an asn1 blob that successfully decodes and have d2iPKCS7() return a valid pointer and have PKCS7typeissigned() also return success but have Pkcs7->d.sign be a NULL pointer.
Reference: https://bugzilla.tianocore.org/showbug.cgi?id=1914
EDK2's Network Package is susceptible to an infinite loop vulnerability when parsing unknown options in the Destination Options header of IPv6. This vulnerability can be exploited by an attacker to gain unauthorized access and potentially lead to a loss of Availability.
EDK2's Network Package is susceptible to a predictable TCP Initial Sequence Number. This vulnerability can be exploited by an attacker to gain unauthorized access and potentially lead to a loss of Confidentiality.
EDK2's Network Package is susceptible to a predictable TCP Initial Sequence Number. This vulnerability can be exploited by an attacker to gain unauthorized access and potentially lead to a loss of Confidentiality.
Last updated 25 August 2025
EDK2's Network Package is susceptible to an out-of-bounds read vulnerability when processing Neighbor Discovery Redirect message. This vulnerability can be exploited by an attacker to gain unauthorized access and potentially lead to a loss of Confidentiality.
EDK2's Network Package is susceptible to an out-of-bounds read vulnerability when processing the IANA or IATA option in a DHCPv6 Advertise message. This vulnerability can be exploited by an attacker to gain unauthorized access and potentially lead to a loss of Confidentiality.
Last updated 25 August 2025
REJECT DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: none. Reason: This candidate was in a CNA pool that was not assigned to any issues during 2019. Notes: none.
On Wed, Feb 14, 2024 at 02:40:43PM +0000, Mate Kukri wrote: Hello,
We have identified a vulnerability resulting from an insecure default configuration of OVMF/AAVMF and similar firmware as used in Ubuntu's edk2 package, the firmware used by LXD, and potentially other similar software.
Said EDK2 based firmwares implement UEFI Secure Boot functionality but also contain a copy of the UEFI Shell, this gives an OS resident attacker (without physical access or pseudo-physical access) the ability to execute arbitrary code at system level, and thus the ability bypass UEFI Secure Boot. Hi Mate,
I'm not sure if I understand everything correctly, but if UEFI Secure Boot is enabled, shouldn't the shell.efi binary need to be explicitely signed in order for it to be correctly loaded? It doesnt look like a good idea to sign shell.efi on a production platform, but for test purposes it might be relevant.
Regards, -- Yves-Alexis Perez