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.