CVE-2021-3929: QEMU NVM Express Controller RCE Vulnerability

CVE-2021-3929 Overview

A DMA reentrancy vulnerability has been identified in the NVM Express Controller (NVME) emulation component of QEMU, the popular open-source machine emulator and virtualizer. This vulnerability, similar to CVE-2021-3750, occurs when a reentrancy write operation triggers the nvme_ctrl_reset() function, causing data structures to be freed prematurely. This results in a use-after-free condition (CWE-416) that can be exploited by a malicious guest operating system.

The vulnerability allows an attacker with privileged access within a guest virtual machine to potentially crash the QEMU process running on the host, leading to a denial of service condition. More critically, successful exploitation could enable arbitrary code execution within the context of the QEMU process on the host system, potentially allowing guest-to-host escape.

Critical Impact

Malicious guest VMs can exploit this use-after-free flaw to crash the host QEMU process or execute arbitrary code, enabling potential guest-to-host escape in virtualized environments.

Affected Products

• QEMU (all versions prior to the security patch)
• Fedora 35
• Fedora 36

Discovery Timeline

• 2022-08-25 - CVE CVE-2021-3929 published to NVD
• 2025-02-28 - Last updated in NVD database

Technical Details for CVE-2021-3929

Vulnerability Analysis

This vulnerability exists within QEMU's NVMe controller emulation, which provides virtual NVM Express storage devices to guest operating systems. The core issue stems from improper handling of DMA (Direct Memory Access) operations during reentrancy scenarios.

When the guest operating system interacts with the emulated NVMe controller, certain write operations can trigger the nvme_ctrl_reset() function in a reentrant manner. During this reset operation, internal data structures are freed while still being referenced by other parts of the code, creating a classic use-after-free condition.

The vulnerability requires local access with high privileges within the guest environment, but the scope extends beyond the vulnerable component—successful exploitation affects the host system's confidentiality, integrity, and availability. This cross-scope impact makes the vulnerability particularly concerning for cloud providers and organizations running untrusted guest workloads.

Root Cause

The root cause is a DMA reentrancy issue in the NVMe controller emulation code. When DMA operations are processed, the code does not properly guard against reentrant calls that may occur during memory-mapped I/O (MMIO) handling. Specifically, the nvme_ctrl_reset() function can be invoked while other operations are still in progress, leading to premature deallocation of data structures that are still in use.

This is categorized as CWE-416 (Use After Free), where memory is accessed after it has been freed, potentially allowing an attacker to corrupt memory or execute arbitrary code.

Attack Vector

The attack requires a malicious actor with privileged access inside a guest virtual machine. The attacker must craft specific sequences of operations against the emulated NVMe controller that trigger the reentrancy condition:

1. The attacker initiates a DMA operation from within the guest VM targeting the NVMe controller
2. During the processing of this operation, a carefully timed write triggers nvme_ctrl_reset()
3. The reset function frees data structures while they are still referenced by the original DMA operation
4. Subsequent access to the freed memory causes undefined behavior, potentially allowing code execution

The vulnerability mechanism involves exploiting the timing between DMA operations and the controller reset function. When a reentrancy write occurs during active DMA processing, the nvme_ctrl_reset() function deallocates memory structures that are still being used by the in-flight DMA operation. This creates a use-after-free condition where the freed memory may be reallocated and corrupted, leading to denial of service or potential code execution on the host.

For detailed technical analysis, see the QEMU Issue #782 Discussion and QEMU Issue #556 Discussion.

Detection Methods for CVE-2021-3929

Indicators of Compromise

• Unexpected QEMU process crashes or segmentation faults on host systems
• Guest VMs exhibiting unusual NVMe controller interactions or repeated reset attempts
• Memory corruption errors in QEMU logs related to NVMe emulation
• Unexplained host system instability when running specific guest workloads

Detection Strategies

• Monitor QEMU process stability and implement crash detection mechanisms for hypervisor processes
• Enable QEMU tracing for NVMe controller operations to identify suspicious patterns
• Deploy memory sanitizers (AddressSanitizer) in development/testing environments to detect use-after-free conditions
• Implement guest VM behavioral analysis to detect unusual NVMe controller interactions

Monitoring Recommendations

• Configure centralized logging for all QEMU processes across the infrastructure
• Set up alerts for repeated QEMU process failures or restarts
• Monitor for signs of guest-to-host escape attempts in virtualized environments
• Track NVMe controller reset frequency and correlate with guest VM activity

How to Mitigate CVE-2021-3929

Immediate Actions Required

• Update QEMU to the latest patched version containing commit 736b01642d85
• Apply vendor-specific patches from Fedora or other distribution maintainers
• Consider disabling NVMe controller emulation for untrusted guest VMs if not required
• Implement additional isolation measures for virtualized environments hosting untrusted workloads

Patch Information

QEMU has released a security fix addressing this vulnerability. The patch is available in QEMU Commit 736b01642d85. Fedora users should update to patched versions as announced in the Fedora Package Announcement.

Additional vendor advisories are available from:

• Red Hat CVE-2021-3929 Advisory
• Red Hat Bug Report #2020298
• NetApp Security Advisory ntap-20250228-0010

Workarounds

• Disable NVMe device emulation for guest VMs where it is not strictly required
• Use alternative storage controller emulation (virtio-blk, IDE) for untrusted guests
• Implement strict guest VM isolation using additional security boundaries
• Limit privileged operations within guest VMs through appropriate access controls

# Example: Configure QEMU without NVMe emulation for untrusted guests
# Use virtio-blk instead of NVMe for storage
qemu-system-x86_64 \
  -drive file=guest-disk.qcow2,if=virtio,format=qcow2 \
  -m 4G \
  -enable-kvm \
  # Avoid using -device nvme for untrusted workloads