CVE-2022-30773 - How TOCTOU DMA Attacks Threatened Insyde SMM Drivers

In mid-2022, Insyde Software publicly disclosed a severe vulnerability tracked as CVE-2022-30773. This security bug opens the door for a Time-of-Check to Time-of-Use (TOCTOU) attack targeting the IhisiSmm driver. Specifically, an attacker with Direct Memory Access (DMA) privileges can change parameters in a buffer after validation but before they’re actually used by the driver, potentially leading to privilege escalation or arbitrary code execution within the highly sensitive System Management Mode (SMM).

Let’s break down this vulnerability, see an example of potential exploitation, and review what was done to patch it.

What is CVE-2022-30773?

With CVE-2022-30773, the risk arises because the IhisiSmm driver—a key part of Insyde’s UEFI system firmware—does not properly lock down parameter buffers passed from less privileged environments. The vulnerable driver would check values inside a memory buffer for security, but then trust the same buffer’s content moments later during use, with nothing preventing malicious DMA-capable devices (or malware) from modifying that memory in the interim.

This is the core of a TOCTOU flaw (CWE-367), aggravated by the potential for DMA abuse.

Description from Advisory

> DMA attacks on the parameter buffer used by the IhisiSmm driver could change the contents after parameter values have been checked but before they are used (a TOCTOU attack). This issue was discovered by Insyde engineering.
> _Fixed in: Kernel 5.4: 05.44.23 and Kernel 5.5: 05.52.23._

For vendor disclosure and patches, see the official advisory.

Background: Why SMM and DMA?

System Management Mode (SMM):
SMM is a special CPU mode (ring -2) used for handling system-wide functions, like power management or firmware-level security. Code running here can access all system resources, and vulnerabilities here can undermine the whole security model.

DMA (Direct Memory Access):
DMA devices (like PCIe peripherals) can directly read or write system memory—sometimes bypassing the CPU and OS checks. Unless properly isolated, a malicious DMA device can inject or change code/data in critical places.

The attack here relies on this simple sequence

1. The OS or an attacker submits a pointer to a buffer (say, param_buffer) to the vulnerable SMM driver via an SMM call.
2. The SMM driver checks the values inside the buffer: e.g., making sure the arguments are valid, permissions are respected, etc.
3. SMM then goes on to use the values from that same buffer—for example, to write firmware, dump memory, etc.
4. In between steps 2 and 3, an attacker (using a compromised DMA device or malware with DMA attack ability) changes the buffer’s contents—maybe giving themselves higher privilege or instructing SMM to perform a malicious action.

Because there’s no copy or locking of the buffer before use, the SMM code uses the attacker’s changed values, potentially causing serious damage.

Suppose the SMM driver expects this structure in memory for its SMI call

typedef struct {
    UINT32 Command;
    UINT32 DataSize;
    UINT8  Data[256];
} IHISI_PARAMS;

The system checks Command and DataSize for allowed values, then uses them.

buf->Command = SAFE_COMMAND;

buf->DataSize = 8; // Small, as allowed
// Fill buf->Data safely

TOCTOU Race

After check but before use, use a privileged DMA device (like a malicious PCIe card or a Thunderbolt device) to overwrite DataSize:

// On DMA device, race to

buf->DataSize = 512; // Very large, maybe triggering buffer overflow

Abuse

SMM code now reads from the corrupted buffer and handles a bigger payload or a forbidden operation, letting the attacker get code execution in SMM or dump secrets.

This kind of attack is very tricky to mitigate once exploitable—because SMM, by design, trusts physical memory unless extra steps are taken.

Code Snippet from a Hypothetical SMM Handler

EFI_STATUS
IhisiSmmHandler(IHISI_PARAMS *UserBuf) {
    // Input validation
    if (UserBuf->DataSize > 256)
        return EFI_INVALID_PARAMETER;
    if (UserBuf->Command == CMD_UNAUTHORIZED)
        return EFI_ACCESS_DENIED;

    // TOCTOU problem: UserBuf could be changed NOW via DMA

    // Unsafe use:
    memcpy(LocalBuffer, UserBuf->Data, UserBuf->DataSize);
    DoIHISICommand(UserBuf->Command, LocalBuffer, UserBuf->DataSize);
}

Vulnerability:
Here, an attacker can change UserBuf->DataSize between the if-statement and the memcpy, making SMM copy more data than allowed, causing overflow or other memory corruption.

How Was It Fixed?

The correct way to fix is to make a local copy of the user buffer *after* checking (or before), and only use the local copy after that point. This prevents any external code (like a malicious DMA device) from changing the data after validation.

Example Patched Code

EFI_STATUS
IhisiSmmHandler(IHISI_PARAMS *UserBuf) {
    IHISI_PARAMS SafeCopy;

    // Atomic copy from DMA buffer to SMM local memory
    CopyMem(&SafeCopy, UserBuf, sizeof(IHISI_PARAMS));

    // Validate SafeCopy
    if (SafeCopy.DataSize > 256)
        return EFI_INVALID_PARAMETER;
    if (SafeCopy.Command == CMD_UNAUTHORIZED)
        return EFI_ACCESS_DENIED;

    // Now use only SafeCopy
    memcpy(LocalBuffer, SafeCopy.Data, SafeCopy.DataSize);
    DoIHISICommand(SafeCopy.Command, LocalBuffer, SafeCopy.DataSize);
}

See release notes for Kernel 5.4: 05.44.23 and Kernel 5.5: 05.52.23.

Reference

- Insyde CVE-2022-30773 Advisory
- Mitre CVE page
- CWE-367: Time-of-Check Time-of-Use (TOCTOU) Race Condition

High Privileged Code Must Never Trust Shared Buffers:

When code with access to sensitive system functions (like SMM) operates on shared memory, it must *always* copy the data locally before use.

DMA Attacks Remain Relevant:

Physical attacker models aren’t the only ones at risk—malware with kernel/driver access can expose the same weaknesses.

Always Apply Firmware Updates:

Insyde’s prompt patch rolled out in 2022. Make sure your system is updated to firmware images built with Kernel 5.4:05.44.23 or newer.

Conclusion

CVE-2022-30773 is a textbook example of how modern UEFI firmware can still be tripped up by classic race conditions, especially when exposed to DMA or privileged attacker models. Proper coding practices—like copying buffers before use—are still the best defense in the low-level firmware world. If you have an Insyde-powered device, check for the newest firmware and make updates part of your security hygiene.

*Author: [Your Name]
Published: June 2024*

Timeline

Published on: 11/14/2022 22:15:00 UTC
Last modified on: 11/18/2022 16:01:00 UTC