In 2022, a serious vulnerability known as CVE-2022-30774 was discovered affecting Insyde’s PnpSmm driver. This bug is not just another buffer overflow or a simple memory corruption. It involves a clever kind of exploitation: Direct Memory Access (DMA) attacks combined with a Time-Of-Check-to-Time-Of-Use (TOCTOU) condition.

In this article, let’s break down the bug in very simple terms, see how it works, and what you can do about it. We’ll also look at some code snippets, how the exploit works, and official fixes from Insyde.

What Is the PnpSmm Driver?

The PnpSmm driver is a part of firmware (like BIOS or UEFI) responsible for managing system resources, particularly with Plug and Play capabilities in System Management Mode (SMM). SMM is a privileged execution mode providing isolated code execution for things like power management and system hardware control.

What Happened?

The PnpSmm driver accepted input data parameters placed in a buffer in memory—let’s call it the "parameter buffer." This buffer was checked for validity. However, there was a critical window between when the parameters were checked and when they were actually used. If the data in the parameter buffer changed between these two points, bad things could happen.

> This is called a *Time-Of-Check-to-Time-Of-Use (TOCTOU)* bug, tracked under CWE-367!

Let’s add an extra twist: If an attacker used Direct Memory Access (DMA), they could alter (race and change) the contents of the buffer—between the check and the use—even if they didn’t have control of the CPU.

DMA Attacks in Simple Words

DMA allows some hardware (like PCI devices) to read or write to the main system memory directly, bypassing the CPU. If a malicious device gains DMA access (for example, through a malicious Thunderbolt device or a compromised PCI device), it can write to any memory location, even while the CPU isn’t looking.

Malicious Device Prepares DMA Buffer

The attacker sets up a PCI device that can write to an area of memory used for the PnpSmm driver parameters.

PnpSmm Driver Initiates Check

The SMM code reads the parameters from this buffer and performs validation (“Is the input safe?”).

DMA Changes Parameter Buffer

After the check but before the SMM driver uses the values, the DMA-capable device quickly overwrites the buffer with malicious data.

PnpSmm Uses Manipulated Data

The SMM code then uses these now-malicious inputs, leading to potential attacks, from privilege escalation to system compromise.

Visual Example: Simplified Pseudocode

void HandlePnpRequest(void *paramBuffer) {
    // 1. Validate input parameters
    if (!IsValid(paramBuffer)) {
        return; // Unsafe input
    }
    // ... DMA attack could change paramBuffer here ...
    // 2. Use parameters, assuming still valid
    DoSomethingWithParams(paramBuffer); // Vulnerable use
}

The problem is that there’s a “gap” between the check and use, giving time for DMA to make changes.

Bypassing traditional OS-level security (since the OS can’t see or control SMM code).

DMA attacks can be done using special hardware (like a malicious Thunderbolt device, or a compromised PCIe card), making this a real threat in environments with physical access or untrusted hardware.

Discovery and Official Fix

This bug was found by Insyde engineering during a routine security review—not by hackers, but by internal staff looking to prevent real-world attacks.

- Insyde published information here: Security Pledge SA-2022043

Kernel 5.5: 05.52.25

If you’re running an Insyde-based BIOS/UEFI, make sure your version is at least as new as these!

Hypothetical Fixed Pseudocode

void HandlePnpRequest(void *paramBuffer) {
    // Copy to SMM-private buffer (not DMA-accessible)
    char safeBuffer[BUFFER_SIZE];
    memcpy(safeBuffer, paramBuffer, BUFFER_SIZE);
    // Validate and use the safe buffer
    if (!IsValid(safeBuffer)) {
        return;
    }
    DoSomethingWithParams(safeBuffer); // Safe: no DMA races possible
}

Update your firmware!

Make sure your PC BIOS/UEFI is up to date with the patched Insyde versions or later.

Restrict physical access:

DMA attacks usually need physical or low-level access—don’t let untrusted hardware or people near your system.

Enable IOMMU (VT-d):

If available, enable Intel VT-d or AMD IOMMU in your BIOS/UEFI settings. This limits unauthorized DMA.

References

- Insyde Security Advisory SA-2022043
- CWE-367: Time-of-check Time-of-use (TOCTOU) Race Condition
- Intel: DMA Attacks and Thunderbolt
- (External writeup on SMM and DMA threats) (PDF)

Conclusion

CVE-2022-30774 is a real-world example of how low-level driver bugs, combined with hardware-level access, can lead to critical security risks. For both security professionals and everyday users, keeping firmware updated and understanding the kinds of physical hardware you plug into your system is key.

Stay safe out there, and always keep an eye out for BIOS/UEFI updates!

Timeline

Published on: 11/15/2022 00:15:00 UTC
Last modified on: 02/14/2023 12:15:00 UTC