Header bannerHeader banner

[BRLY-2022-025] SMM memory leak vulnerability in SMM driver (SMRAM read).

September 21, 2022


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-025
  • Insyde PSIRT assigned CVE identifier: CVE-2022-35896
  • FwHunt rule: BRLY-2022-025
  • 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 FvbServicesRuntimeDxe 84A3AC77B498004DEAE28A98E37BFE7C00775432385D9F20884CE31414FCE815 BDFE5FAA-2A35-44BB-B17A-8084D4E2B9E9

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 145f21ab-d92c-4eab-ab1e-5d24b90c3c6c:

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

Also, it locates the protocol with GUID 2970687c-618c-4de5-b8f9-6c7576dca83d (implemented in SMM driver FwBlockServiceSmm GUID 74D936FA-D8BD-4633-B64D-6424BDD23D24):

gBuffer = AllocateBuffer(0x10);
  if ( gSmst->SmmLocateProtocol)(&gUnknownProtocol2970687CGuid, 0, gBuffer + 8) >= 0 )

The handler is located at offset 0x2DC8:

EFI_STATUS __fastcall SmiHandler(EFI_HANDLE DispatchHandle, const void *Context, void *CommBuffer, UINTN *CommBufferSize)
  if ( !CommBuffer )
    return 0;
  if ( !CommBufferSize )
    return 0;
  CommBufferSize_val = *CommBufferSize;
  if ( *CommBufferSize != gCommBufferSize - 0x18 || CommBuffer != (char *)gCommBuffer + 0x18 )
    return 0;


  if ( *((_DWORD *)CommBuffer + 2) == 'AFMS' )
    v8 = (char *)CommBuffer + 0x20;
    v9 = (char *)CommBuffer + 0x28;
    if ( *((_QWORD *)CommBuffer + 4) <= *CommBufferSize - 0x28 )
      Status = EFI_UNSUPPORTED;

      cmd = *((_DWORD *)CommBuffer + 6);
      UnknownProtocol297067C = *(_QWORD *)(gBuffer + 8);    // gSmst_2->SmmLocateProtocol)(&gUnknownProtocol297067CGuid, 0, gBuffer + 8)

      if ( cmd )
      // cmd = 0
      {                                         // SmfbFunc1: SMM memory read
        Status = (*(UnknownProtocol297067C + 8))(
                   *(_QWORD *)(gBuffer + 8),
                   *((_QWORD *)CommBuffer + 2),
                   (char *)CommBuffer_1 + 0x20,
                   (char *)CommBuffer_1 + 0x28);

      goto LABEL_18;
  return 0;

As we can see if a caller specifies *((_DWORD *)CommBuffer + 6) = 0 routine (*(UnknownProtocol297067C + 8))() will be called. It is implemented in SMM driver FwBlockServiceSmm GUID 74D936FA-D8BD-4633-B64D-6424BDD23D24, we call it as SmfbFunc1() (located at offset 0x1E54) with controllable arguments passed into it:- 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 input 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.

This vulnerability is explotiable from the runtime.

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