Last updated: June 2024  
Author: QEMU Security Enthusiast


When you're running virtual machines (VMs) on QEMU, the software acts as the bridge between the guest (the VM) and your real hardware. For performance and flexibility, QEMU emulates a lot of hardware, including something called an SD Host Controller Interface (SDHCI). That's what lets guest VMs read and write to SD cards (real or virtual).

In October 2022, a critical bug was discovered in QEMU’s emulated SDHCI device, tracked as CVE-2022-3872. This vulnerability is an "off-by-one read/write" issue. Let’s break down what this means, how it’s exploited, and what you can do about it — all in plain English.

What is CVE-2022-3872?

Summary:  
A QEMU bug in the SDHCI device allows a *malicious guest* VM to read or write one extra byte beyond the intended memory buffer when using the Buffer Data Port Register. This could crash the QEMU process, causing a denial of service (DoS) on the host.

Impact:

Result: QEMU process crash (DoS)

- Potential risk: Someone renting a VM could crash your host and knock out all other VMs using QEMU

The Off-By-One Explained (With Code)

This bug happens because of a *logic error* in two key code sections: how QEMU handles reading and writing data to the SDHCI buffer, specifically in sdhci_read_dataport() and sdhci_write_dataport().

What Is Off-By-One?

Off-by-one means the code lets you read or write *just one* more element (byte, in this case) than the buffer was designed for. This often leads to memory corruption or crashes.

Code Snippet: The Vulnerable Code

The original patch/commit shows the fix, but let’s see what was wrong:

The Problem

// Pseudocode to illustrate the issue:
if (sdhci->data_count <= s->block_size) {
    value = sdhci->data[s->data_count];
    sdhci->data_count++;
}

If data_count == block_size, this condition *still* passes (<=), but data is only valid up to block_size - 1. Thus, this allows one extra read/writer over the allocated buffer boundary.

The Correct Logic

// Should have been:
if (sdhci->data_count < s->block_size) {
    value = sdhci->data[s->data_count];
    sdhci->data_count++;
}

The Real QEMU Diff

Here’s part of the fix from the real QEMU commit:

-    if (sdhci->data_count <= sdhci->block_size) {
+    if (sdhci->data_count < sdhci->block_size) {

Here’s how a real exploit might work, step by step

1. Malicious Guest Code: A guest OS user or root process runs code that interacts with the SDHCI device.
2. Trigger Off-By-One: The code reads/writes to the Buffer Data Port Register when data_count == block_size.
3. Out-of-Bounds (OOB) Access: QEMU (on the host) reads or writes one byte after the intended buffer.
4. QEMU Crash: This can cause a segmentation fault if the memory beyond the buffer isn't valid, crashing the whole QEMU process, effectively shutting down the VM and possibly others.
5. Denial of Service: The attacker has now denied service to the host QEMU process, impacting all workloads running under it.

Note:  
There’s no known practical way to escalate privileges or execute arbitrary code on the host due to this specific bug, but causing a host reboot or process crash is definitely possible (and already bad).

Proof-of-Concept Example (Guest Side, C Code)

Here's a simplified idea of what guest code could look like to intentionally trigger the off-by-one condition:

#define SDHCI_BUFFER_REGISTER x20
#define BLOCK_SIZE 512

// Pseudocode: this runs on GUEST OS, not on HOST!
void trigger_vuln() {
    volatile unsigned int *sdhci_buff = (unsigned int *) SDHCI_BUFFER_REGISTER;
    for (int i = ; i < BLOCK_SIZE + 1; ++i) {
        sdhci_buff[] = xdeadbeef; // Write past the end on +1
    }
}


*Note: In reality, you need guest privileges to access the emulated SDHCI controller, like root on a Linux VM.*

Who’s Affected?

- QEMU users: Version before the patch (October 2022)
- Any VM setup using SDHCI: Especially shared hosting, cloud providers, CI/CD services

How to Fix (Mitigation and Remediation)

- Update QEMU. Always use the latest stable version or apply the official patch.
- Restrict untrusted guest access. Where possible, avoid giving guests direct access to SDHCI unless absolutely needed.

References

- QEMU Patch for CVE-2022-3872
- National Vulnerability Database Entry
- QEMU Official Security Track

Final Thoughts

Off-by-one bugs might seem small, but in the complex world of virtualization, even a single extra read or write can be disastrous. QEMU is a widely-used, powerful tool — make sure yours isn't vulnerable to CVE-2022-3872. Patch fast, monitor, and stay safe!

Need more details or code? Let us know in the comments or issues section below.


*This guide was written exclusively for clarity, using simple, plain language for everyone learning about QEMU security.*

Timeline

Published on: 11/07/2022 21:15:00 UTC
Last modified on: 02/23/2023 01:35:00 UTC