Latest Automata Findings: SMM Callout Vulnerabilities in UEFI
Eclypsium Automata has identified multiple, separate SMM callout vulnerabilities in UEFI modules supplied by AMD and leading firmware vendor AMI. These vulnerable modules can allow attackers to execute arbitrary code in the highly privileged System Management Mode (SMM), which UEFI/BIOS uses during runtime to control low-level device functions independently of the operating system.
Note: Eclypsium customers can use the supply chain security platform to detect the vulnerabilities presented in this article. Please contact your solutions team for more information and to enable these features.
We initially identified the AMI issue on a Dell device, and Dell has released updates for their affected products. However, given that AMI is one of the leading vendors in the BIOS supply chain, it is highly likely that other OEM vendors and models are affected. Likewise, we initially identified an AMD vulnerability on Lenovo rack servers (models SR635 and SR655), and Lenovo has issued an advisory. AMD’s security bulletin notes that the issue affects AMD EPYC™ 2nd Gen Processors, which are used in various vendors’ and platforms.
Quick Background on SMM and SMM Callouts
The role of system firmware doesn’t end with the boot process. Devices must manage various low-level runtime tasks such as power management, configuring hardware components, and the Trusted Platform Module (TPM). These and other runtime firmware tasks are the job of SMM (System Management Mode).
However, devices must ensure that SMM and the operating system don’t step on each other’s toes. To avoid conflicts, the system can issue System Management Interrupts (SMIs), which briefly halt the OS and free SMM to perform its low-level functions transparently from the OS.
Naturally, this ability to effectively freeze time in the OS and make low-level changes is incredibly powerful. If an attacker gains control over SMM execution, then malicious actions remain invisible to the operating system and any applications or security tools running within it.
Thus, for security reasons, the SMM code resides in a specialized and protected address space (System Management RAM or SMRAM), which the OS or applications can’t access. However, an “SMM callout” vulnerability occurs when SMM code calls a function outside the SMRAM boundaries, such as an SMI handler invoking a UEFI boot service or runtime service as part of its operation. Attackers with OS privileges could modify these instructions outside the protected boundary, thereby hijacking the privileged execution flow. You can refer to our previous research for more insight into how SMM can be abused in the context of a threat.
Vulnerability Analysis
Eclypsium Automata identified multiple UEFI modules with SMM callout vulnerabilities. The vulnerabilities involve modules making unsafe calls in the context of SMI handlers to functions in the Boot Services Table. Attackers could modify the Boot Services Table entries to point to their malicious code and then trigger the SMI handlers to execute the attacker’s code in system management mode.
The first two vulnerabilities are tied to two drivers, SmmTcgStorageSec and NvmeSmm, and the AMD vulnerability is tied to AmdPlatformRasSspSmm. We will look at each of these separately.
NvmeSmm (CVE-2024-47238)
An SMI handler, located in the UEFI module NvmeSmm, calls the AllocatePages service function. The handler is registered with the GUID EC2BD1FD-E3B0-429B-ADDF-9657935A3684.
- Affected vendors and devices:
- Dell Edge Gateway 5100 (2024-05 1.28.0 BIOS update)
- Driver details
- Driver GUID: E5E2C9D9-5BF5-497E-8860-94F81A09ADE0
- Driver SHA256: 2ae10290f0d06a8107e267a81ec21b9ba7cff0f8beb6b5c66d0e643288ec1a5c and others (Dell)
Sample pseudo code:
EFI_STATUS
child_smm_handle(EFI_HANDLE DispatchHandle,void *Context,void *CommBuffer,UINTN *CommBufferSize)
{
....
if (DAT_80001e08 == 0) {
EVar3 = (*gBS_2->AllocatePages)
( ....);
....
As mentioned earlier, Dell released this advisory in December 2024 to address the vulnerability.
SmmTcgStorageSec
Two SMI handlers, located in the UEFI module SmmTcgStorageSec, call the LocateProtocol service function. The handlers are registered with the GUIDs B8A9D34B-0C97-4854-93B6-66713DDB48F6 and 7C0FC2A2-D0A3-4196-9E0F-E7DA404378AB. We are unaware of any vulnerable devices at this time, but will update this post if any are discovered.
- Driver details
- Driver GUID: 6B85F263-F584-44F8-BB5D-F02C40795D8E
- Driver SHA256: fd241bf1e67ae07ea61cc884e1c74ce57a4b604821c09240b6a7acebef076d45
Sample pseudo code:
EFI_STATUS
child_smm_handler
(EFI_HANDLE DispatchHandle,void *Context,void *CommBuffer,UINTN *CommBufferSize)
{
...
if ((gS3SaveStateProtocol_3 != (EFI_S3_SAVE_STATE_PROTOCOL *)0x0) ||
(EVar4 = (*gBS_2->LocateProtocol)
(&gEFI_S3_SAVE_STATE_PROTOCOL_GUID_10,(void *)0x0,
&gS3SaveStateProtocol_3),
...
}
(EVar4 = (*gBS_2->LocateProtocol)
(&gEFI_S3_SAVE_STATE_PROTOCOL_GUID_10,(void *)0x0,
&gS3SaveStateProtocol_3),
...
}
AmdPlatformRasSspSmm (CVE-2024-21924)
An SMI handler, located in the UEFI module AmdPlatformRasSspSmm, calls twice the FreePool service function. The vulnerability has been assigned as CVE-2024-21924 with a CVSS v3 score of 8.2.
- Affected vendors and components:
- Lenovo: SR635 rack servers (2024-03 cfe142e-7.30 BIOS update, link), SR655 rack servers (2021-09 6.20 update).
- AMD EPYC™ 2nd Gen Processors and H11 and H12 generations of products.
- Driver details:
- Driver GUID: F8356C42-4BA6-706F-59E9-A9B1AFF2BCD8
- Driver SHA256: 36535ed11460ed07129650b95dbd6209a5e850f29fba391d09097a1e2d3ab8bf
child_smm_handler(EFI_HANDLE DispatchHandle,void *Context,void *CommBuffer,UINTN *CommBufferSize)
{
....
puVar5 = (ushort *)(*gBS_3->FreePool)(local_20);
...
puVar6 = (ushort *)(*gBS_3->FreePool)(Buffer);
....
}
As mentioned earlier, AMD released this advisory and Lenovo released a similar advisory in February 2025, both containing mitigations to address the vulnerability.
Risks to the Technology Supply Chain
These vulnerabilities are another example of how seemingly small mistakes can cause significant issues in the technology supply chain. AMD is one of the industry’s most important suppliers of processors and motherboards. For its part, AMI is one of the industry’s most popular sources of firmware, with its code being used by a wide range of leading OEMs. This collectively creates the potential for mistakes to find their way into the most fundamental and privileged code of many different products and types of devices.
More importantly, low-level weaknesses such as SMM callouts can cut through the supply chain in another way – by subverting the many protections and technologies that run on the hardware. Modern devices naturally rely on deeply layered sets of defenses. However, most of these protections are tied to the OS itself or applications that depend on the OS, such as an EDR. By gaining runtime control of SMM, attackers can freeze this entire stack whenever they want, running their malicious code without oversight.
So ultimately, this means that these types of supply chain vulnerabilities can find their way into many, many kinds of hardware, and when they do, the rest of the software supply chain is forced to go along for the ride. If you have questions regarding this or any prior Eclypsium research, please contact the team at [email protected].
