Skip to content

CVE-2020-12928

AMD Ryzen Master, arbitrary physical memory read/write via IOCTL

Summary

Field Value
Driver AMDRyzenMasterDriver.sys
Vendor AMD
Vulnerability Class Arbitrary R/W / Physical Memory Mapping
Abused Version Versions prior to 2.2.0.0
Status Patched — updated driver removes unrestricted memory access IOCTLs
Exploited ITW No

The Story

AMD Ryzen Master is a CPU overclocking and monitoring utility for AMD Ryzen processors. h0mbre discovered that its kernel component, AMDRyzenMasterDriver.sys, exposes IOCTLs for physical memory access via MmMapIoSpace with user-controlled physical address parameters and no range validation. The IOCTLs exist to support hardware register manipulation for CPU tuning, but the unrestricted address parameter means any physical address can be mapped, not just AMD CPU-specific registers.

h0mbre's blog post is one of the most detailed and educational BYOVD writeups available. It walks through the entire process: reverse engineering the IOCTL dispatch table, identifying the physical memory mapping calls, understanding the page table hierarchy, and building the exploitation chain step by step. For researchers learning BYOVD exploitation, this writeup is required reading.

AMD patched the vulnerability in version 2.2.0.0, restricting the physical memory access IOCTLs to authorized ranges. However, older signed versions of the driver remain deployable on systems without blocklist enforcement.

BYOVD Context

  • Driver signing: Authenticode-signed by Advanced Micro Devices with valid certificate
  • Vulnerable Driver Blocklist: Older versions included in Microsoft's recommended driver block rules
  • HVCI behavior: Older versions blocked on HVCI-enabled systems
  • KDU integration: Not integrated
  • LOLDrivers: Listed at loldrivers.io

Affected IOCTLs

  • Arbitrary physical memory read via MmMapIoSpace
  • Arbitrary physical memory write via MmMapIoSpace

Walking the Page Tables to SYSTEM

h0mbre's exploitation approach follows the standard physical memory BYOVD pattern, but the writeup explains each step in detail. After loading the driver and opening the device handle, the physical memory read IOCTL is used to traverse the four-level page table hierarchy (PML4 -> PDPT -> PD -> PT), translating virtual addresses to physical addresses. The current process's EPROCESS structure is located in physical memory, the SYSTEM process token is found by walking the ActiveProcessLinks list, and the physical memory write IOCTL copies the SYSTEM token into the current process. The process now runs as SYSTEM.

The educational value of h0mbre's writeup lies in how it demystifies page table walking. For researchers who understand BYOVD conceptually but have not implemented a physical memory exploitation chain, this is the most accessible starting point.

Detection

YARA Rule

rule CVE_2020_12928_AMDRyzenMaster {
    meta:
        description = "Detects vulnerable AMD Ryzen Master driver"
        cve = "CVE-2020-12928"
        author = "KernelSight"
        severity = "high"
    strings:
        $mz = { 4D 5A }
        $driver_name = "AMDRyzenMasterDriver" wide ascii nocase
        $amd = "Advanced Micro Devices" wide ascii
        $ryzen = "RyzenMaster" wide ascii nocase
    condition:
        $mz at 0 and ($driver_name or $ryzen) and $amd
}

ETW Indicators

Provider Event / Signal Relevance
Microsoft-Windows-Kernel-File Driver load event Detects loading of AMDRyzenMasterDriver.sys
Sysmon Event ID 6 — Driver loaded Hash and signature capture
Microsoft-Windows-Security-Auditing Event 4697 — Service installed Driver service creation
Microsoft-Windows-Kernel-Process Process token modification Post-exploitation token swap

Behavioral Indicators

  • Loading of older AMDRyzenMasterDriver.sys versions (pre-2.2.0.0) outside AMD Ryzen Master installation
  • Physical memory mapping IOCTLs targeting non-CPU-register physical addresses
  • Page table traversal patterns in physical memory read sequences
  • Privilege escalation following AMD driver interaction

Broader Significance

CVE-2020-12928 is significant less for the vulnerability itself (which follows the standard vendor utility BYOVD pattern) and more for the quality of h0mbre's educational writeup. The blog post serves as a practical tutorial for physical memory BYOVD exploitation, making it one of the most-referenced resources for researchers learning this technique. It also demonstrates that major CPU vendors like AMD face the same driver security challenges as motherboard and peripheral vendors: the need for hardware register access in legitimate utilities creates the same unrestricted primitives that attackers exploit.

References