Skip to content

CVE-2019-8372

LG Device Manager LHA, arbitrary kernel write via insufficient IOCTL validation

Summary

Field Value
Driver LG LSB driver (lha.sys / LgCoreTemp.sys)
Vendor LG Electronics
Vulnerability Class Arbitrary Write / IOCTL Access Control
Abused Version Various versions shipped with LG Device Manager
Status Withdrawn — driver removed from LG software
Exploited ITW No

The Story

LG Device Manager ships a kernel driver for laptop management features like temperature monitoring and power management. Jackson Thuraisamy discovered that the driver exposes an IOCTL that writes to arbitrary kernel memory addresses with no validation whatsoever. The user-supplied buffer contains a target address and a value, and the driver writes the value directly to the address.

This is not a buffer overflow or a race condition. It is a design choice: the IOCTL handler takes an address from user mode and writes to it in kernel mode, trusting that only the legitimate LG utility would ever call it. The device object has permissive ACLs, so any process can open a handle and send the write IOCTL.

Thuraisamy documented the complete discovery and exploitation process at jackson-t.ca, walking through how the arbitrary write primitive can be leveraged for local privilege escalation.

BYOVD Context

  • Driver signing: Authenticode-signed by LG Electronics 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

  • Arbitrary kernel memory write via IOCTL with user-controlled address and value

From a Single Write to SYSTEM

The exploitation chain demonstrates how a single arbitrary write primitive can be amplified into full kernel control. The attacker opens the device handle through the permissive ACLs and sends the write IOCTL with a carefully chosen target: the PreviousMode field of the current thread's KTHREAD structure. Writing zero to this field switches the thread from UserMode to KernelMode, causing all subsequent NtReadVirtualMemory and NtWriteVirtualMemory calls to bypass ProbeForRead/ProbeForWrite checks.

With PreviousMode zeroed, the attacker has full arbitrary read/write over the entire kernel address space using standard Nt* APIs. From there, locating the SYSTEM token and swapping it into the current process is the standard escalation path.

The key insight is that a single write to the right location is sufficient for full compromise. The attacker does not need to spray the heap, win a race, or chain multiple primitives. One write to PreviousMode unlocks everything.

Detection

YARA Rule

rule CVE_2019_8372_LG_Driver {
    meta:
        description = "Detects LG LSB vulnerable driver"
        cve = "CVE-2019-8372"
        author = "KernelSight"
        severity = "high"
    strings:
        $mz = { 4D 5A }
        $lha = "lha.sys" wide ascii nocase
        $lg_core = "LgCoreTemp" wide ascii nocase
        $lg = "LG Electronics" wide ascii
    condition:
        $mz at 0 and ($lha or $lg_core or $lg)
}

ETW Indicators

Provider Event / Signal Relevance
Microsoft-Windows-Kernel-File Driver load event Detects loading of LG driver
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 LG kernel driver outside of LG Device Manager installation
  • Arbitrary write IOCTL calls from non-LG processes
  • PreviousMode modification on the current thread following IOCTL interaction
  • Privilege escalation from medium to SYSTEM integrity after driver interaction

Broader Significance

CVE-2019-8372 demonstrates the minimum BYOVD primitive needed for full kernel compromise: a single arbitrary write. When the target is PreviousMode, one write converts a constrained primitive into unrestricted kernel access. This pattern recurs across the BYOVD landscape and highlights why even "limited" write primitives (as opposed to full read/write drivers) should be treated as critical. For driver developers, the lesson is that any IOCTL accepting a kernel address from user mode is a privilege escalation vulnerability, regardless of what value it writes.

References