How a Hyper‑V Deep‑Dive Uncovered Microsoft’s Hidden CVE‑2024‑21305 Bug

Background and Spark

A tweet by @cr3ghost highlighted Satoshi Tanda’s accidental discovery of a severe Hyper‑V bug while studying the hypervisor and HVCI implementation. The community noted the difficulty of understanding such a large system and praised the insight gained from deep learning.

Research Setup

Tanda built hvext.js, a WinDbg extension for Intel‑based Hyper‑V, to dump extended page tables (EPT) and examine HVCI. On three of seven Intel devices (spanning generations 6 to 10) he observed guest physical addresses (GPA) marked as readable, writable, and executable (RWX) – a state that should not exist when HVCI is enabled.

Technical Details of CVE‑2024‑21305

3.1 Impact

The vulnerability, disclosed and patched in the January 9 2024 Windows update, permits arbitrary kernel‑mode code execution, effectively bypassing HVCI protection in the root partition.

3.2 Exploitation Process

Tanda wrote a driver that remapped a chosen linear address to one of the RWX GPAs and placed shellcode there. The driver successfully executed the shellcode, whereas a correctly functioning HVCI should have prevented the write and caused a blue‑screen.

3.3 Root‑Cause Investigation

Initial analysis showed the RWX GPAs contained zeros and were outside NTOS‑managed memory. Further probing revealed they belong to a reserved region reported by the DMAR ACPI table’s RMRR structures, but the UEFI memory map did not list them as Reserved.

3.4 Underlying Mechanism: Intel VT‑d and RMRR

Intel VT‑d protects device access to memory reserved for other VMs or the hypervisor. The DMAR ACPI table’s RMRR entries describe memory that must remain accessible for DMA. BIOS should mark these regions as Reserved in the UEFI memory map, and the OS should identity‑map them with read/write permissions when DMA remapping is enabled.

BIOS must report RMRR‑described physical memory as Reserved.

When the OS enables DMA remapping, it must set up a second‑level address translation for RMRR regions with RW permissions.

Trigger Conditions

On firmware with the bug, the RMRR region is omitted from the UEFI memory map, so the hypervisor cannot apply the correct identity mapping. Consequently, the region retains executable permission, violating HVCI expectations.

Microsoft’s Fix

Firmware Update : All commercial devices receive firmware that forces inclusion of RMRR regions in the UEFI map.

Hyper‑V Compatibility Patch : The hypervisor now strips the executable (X) bit from all RMRR pages, even on buggy firmware, after confirming negligible compatibility impact.

Impact and Significance

The patch was released on January 9 2024, but not every device is affected. Users can detect vulnerable systems by checking that the UEFI Shell memmap command does not list the exact RMRR region as Reserved.

Tanda’s work illustrates how deep system understanding can lead to unexpected vulnerability discovery, and his blog also covers related topics such as Intel VT‑rp, kernel shadow stacks, SMM isolation, and Hyper‑V security policies.

Open‑Source Contributions

DdiMon : Hyper‑V‑based covert EPT kernel‑API monitor.

UEFI Hyper‑V : A UEFI hypervisor capable of booting a full OS.

Minimal Hyper‑V for Intel and AMD .

Hyper‑V Development Training : Course material for building a hypervisor from scratch.

These projects have been forked by game‑cheat developers, showing how research code can become part of a broader ecosystem.

Takeaways for Security Researchers

Deep learning of system internals can uncover critical bugs.

Complex systems like Windows can hide vulnerabilities despite extensive testing.

Cross‑layer interactions between BIOS firmware and the hypervisor are a common source of security issues.

Even mature defenses such as HVCI require continuous auditing and improvement.