Skip to content

CVE-2019-18845

Patriot Viper RGB driver, physical memory read/write via unrestricted IOCTL

Summary

Field Value
Driver Viper RGB driver
Vendor Patriot Memory
Vulnerability Class Arbitrary R/W / Physical Memory Mapping
Abused Version 1.0
Status Withdrawn — driver removed from Patriot software suite
Exploited ITW No

The Story

Of all the reasons for a kernel driver to expose full physical memory access, controlling the RGB LEDs on RAM sticks might be the most absurd. The Patriot Viper RGB driver is a kernel component for Patriot's Viper RGB DRAM lighting control software. The LEDs are controlled via SPD (Serial Presence Detect) registers accessible through physical memory mapping, so the driver exposes IOCTLs that call MmMapIoSpace with user-controlled physical addresses. The problem is that the IOCTLs impose no restriction on the address range. Instead of limiting access to the SPD region, they allow mapping of any physical address on the system.

The device object has permissive ACLs, so any process can open a handle. ActiveCyber documented the vulnerability discovery and exploitation.

This is a case study in disproportionate attack surface. The driver exists to change LED colors. It accidentally provides full kernel memory access to any process on the system. The gap between intended functionality (write a few bytes to SPD registers) and actual capability (read/write all physical memory) makes this one of the more memorable examples of the vendor utility BYOVD pattern.

BYOVD Context

  • Driver signing: Authenticode-signed by Patriot Memory with valid certificate
  • Vulnerable Driver Blocklist: Not included in Microsoft's recommended driver block rules
  • HVCI behavior: May load on HVCI-enabled systems if not hash-blocked
  • KDU integration: Not integrated
  • LOLDrivers: Listed at loldrivers.io

Affected IOCTLs

  • Physical memory read via MmMapIoSpace
  • Physical memory write via MmMapIoSpace

How It Gets Exploited

The exploitation is straightforward. Open the device handle through the permissive ACLs, map arbitrary physical memory regions via the IOCTL, walk page tables to locate kernel structures, and modify EPROCESS tokens for privilege escalation. No race conditions, no heap layout manipulation, and no sophisticated techniques required.

While this driver was not observed in active threat campaigns, it demonstrates an important reality about the BYOVD landscape: vulnerable drivers can emerge from the most unexpected corners of the hardware ecosystem. Any peripheral that requires physical memory access for hardware control, whether for LEDs, fans, temperature sensors, or clock settings, is a potential source of kernel exploitation primitives.

Detection

YARA Rule

rule CVE_2019_18845_ViperRGB {
    meta:
        description = "Detects Patriot Viper RGB vulnerable driver"
        cve = "CVE-2019-18845"
        author = "KernelSight"
        severity = "high"
    strings:
        $mz = { 4D 5A }
        $viper = "Viper" wide ascii nocase
        $patriot = "Patriot" wide ascii
        $rgb = "RGB" wide ascii
    condition:
        $mz at 0 and $patriot and ($viper or $rgb)
}

ETW Indicators

Provider Event / Signal Relevance
Microsoft-Windows-Kernel-File Driver load event Detects loading of Viper RGB driver
Sysmon Event ID 6 — Driver loaded Hash and signature capture
Microsoft-Windows-Security-Auditing Event 4697 — Service installed Driver service creation

Behavioral Indicators

  • Loading of Patriot Viper RGB driver outside of the Viper RGB software suite
  • Physical memory mapping IOCTLs targeting addresses outside the SPD register range
  • Privilege escalation following driver interaction

Broader Significance

CVE-2019-18845 is the poster child for disproportionate attack surface in hardware utility drivers. An RGB LED controller should not provide kernel memory access. The vulnerability exists because the driver developer did not scope the MmMapIoSpace call to only the SPD register range, likely because restricting it would have required additional engineering effort for a feature that "worked" without it. For defenders evaluating BYOVD risk, the lesson is clear: any signed driver that calls MmMapIoSpace with user-controlled parameters is a potential BYOVD weapon, regardless of how mundane its intended purpose.

References