SMM memory leak vulnerability in SMM driver (SMRAM read).
BINARLY efiXplorer team


BINARLY efiXplorer team identified an SMM memory leak vulnerability, which allows an attacker to read portions of SMRAM memory. This in turn could help building a successful attack vector exploiting SMM memory corruption vulnerability.

Vulnerability Information

  • BINARLY internal vulnerability identifier: BRLY-2022-018
  • Insyde PSIRT assigned CVE identifier: CVE-2022-35894
  • FwHunt rule: BRLY-2022-018
  • CVSS v3.1 6.0 Medium CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:C/C:H/I:N/A:N

Affected HP firmwares with confirmed impact by Binarly team

Fimware Module name Module SHA256 File GUID
Framework_Laptop_12th_Gen_Intel_Core_capsule_EFI_signed_allsku_3.01.bin FwBlockServiceSmm 76FA6B5D3F5E59FCD3CA6CDEF9B9D8F0C9B879AF13EFE25CF3E208B7358A6D0B 74D936FA-D8BD-4633-B64D-6424BDD23D24

Potential impact

An attacker can exploit this vulnerability to elevate privileges from ring 0 to ring -2, execute arbitrary code in System Management Mode - an evironment more privileged than operating system (OS) and completely isolated from it. Running arbitrary code in SMM additionally bypasses SMM-based SPI flash protections against modifications, which can help an attacker to install a firmware backdoor/implant into the BIOS. Such a malicious firmware code in the BIOS could persist across operating system re-installs. Additionally, this vulnerability potentially could be used by threat actors to bypass security mechanisms provided by the UEFI firmware (for example, Secure Boot and some types of memory isolation for hypervisors).

Vulnerability description

The vulnerable module registers a child SW SMI handler with GUID 2970687c-618c-4de5-b8f9-6c7576dca83d:

gSmst->SmiHandlerRegister)(SmiHandler, &UNKNOWN_PROTOCOL_2970687C_GUID, &Handle);

Also, it installs protocol with the same GUID 2970687c-618c-4de5-b8f9-6c7576dca83d:

Buffer = (char *)AllocPoolWrapper((EFI_MEMORY_TYPE)(gSmramMap != 0i64 ? 6 : 4), 0x58ui64);
gSmfbFuncArray = Buffer;
if ( !Buffer )

ZeroMemory(Buffer, 0x58ui64);
SmfbFuncArray = (_QWORD *)gSmfbFuncArray;

*(_DWORD *)gSmfbFuncArray = 'bfms';
byte_80006B30 = 0;
SmfbFuncArray[9] = &byte_80006B30;
SmfbFuncArray[2] = SmfbFunc0;
SmfbFuncArray[3] = SmfbFunc1;
SmfbFuncArray[4] = SmfbFunc2;
SmfbFuncArray[5] = SmfbFunc3;
SmfbFuncArray[6] = SmfbFunc4;
SmfbFuncArray[7] = SmfbFunc5;
SmfbFuncArray[8] = SmfbFunc6;

Handle = 0;
gSmst->SmmInstallProtocolInterface)(&Handle, &UNKNOWN_PROTOCOL_2970687C_GUID, 0);

The handler is located at offset 0x19D0:

EFI_STATUS __fastcall SmiHandler(EFI_HANDLE DispatchHandle, const void *Context, void *CommBuffer, UINTN *CommBufferSize)
  if ( CommBuffer && CommBufferSize && !gExitBootServicesFlag2EfiEventLegacyBootFlag )


    v6 = (char *) gUnknownProtocol74d936fa;


    if ( *CommBufferSize == qword_80006B20 - 24 && CommBuffer == v6 + 0x18 )
      switch ( *(_QWORD *)CommBuffer )
        case 2:
          if ( *((_QWORD *)CommBuffer + 3) <= 0x1000 )
            v7 = SmfbFunc1(
                   *((_QWORD *)CommBuffer + 2),
                   (_QWORD *)CommBuffer + 3,
                   (__int64)(CommBuffer + 0x20));
            goto LABEL_17;

As we can see before EFI_EVENT_EXIT_BOOT_SERVICES is triggered, if a caller specifies*(_QWORD *)CommBuffer = 2 routine SmfbFunc1() will be invoked (located at offset 0x1E54) with controllable arguments:

  • addr (retrieved *((_QWORD *)CommBuffer + 2)) - main pointer for the operation
  • size (located at (_QWORD *)CommBuffer + 3) - size of data for the operation
  • dest (the rest of Communication Buffer located at (__int64)(CommBuffer + 0x20)) - destination buffer address for the operation (if applicable)
__int64 __fastcall SmfbFunc1(__int64 a1, __int64 addr, __int64 offset, _QWORD *size_ptr, __int64 dest)
  src = (const void *)(offset + addr);
  size = *size_ptr;

  if ( *(_DWORD *)gValueInitializedByUnknownProtocol1c2e4602 == 3 )
    return sub_800031CC(size, dest, src);  // SMM memory read from a controllable address
  if ( *(_DWORD *)gValueInitializedByUnknownProtocol1c2e4602 > 1u )

  v7 = 0;
  if ( size && (const void *)dest != src )
    memcpy((void *)dest, src, *size_ptr);  // SMM memory read from a controllable address

  return v7;

Because no validation is applied for the addr argument, a possible attacker can make it to point into SMRAM contents. Then memcpy() or sub_800031CC() will lead to copying memory from addr to dest. Hence, this primitive could be used by an attacker for dumping SMRAM contents which in turn helps building attack vectors on exploiting SMM memory corruption vulnerabilities in case an attacker needs to know some information about addresses.

Despite the vulnerability cannot be exploited from the operating system an attacker capable of executing code in DXE phase could exploit this vulnerability to escalate privileges to SMM (ring -2).

Disclosure timeline

This bug is subject to a 90 day disclosure deadline. After 90 days elapsed or a patch has been made broadly available (whichever is earlier), the bug report will become visible to the public.

Disclosure Activity Date
Framework PSIRT is notified 2022-06-27
Insyde PSIRT confirmed reported issue 2022-07-19
Insyde PSIRT assigned CVE number 2022-07-25
BINARLY public disclosure date 2022-09-21


BINARLY efiXplorer team