CVE-2025-8061 — Lenovo LnvMSRIO.sys BYOVD (Arbitrary MSR + Physical Memory)

Last updated: 2026-04-28 Component: Lenovo LnvMSRIO.sys (versions ≤ 3.1.0.36) — userland-accessible kernel driver Bug Class: Improper access control + intentional dangerous IOCTLs (arbitrary MSR R/W, arbitrary physical memory R/W) Patch: Lenovo driver versions 3.1.0.41+ (released September 9, 2025) Exploited ITW: Demonstrated; broader BYOVD ecosystem regularly weaponizes drivers of this shape Discoverer: Luis Casvella (Quarkslab) Related: Mitigations, Privilege Escalation (BYOVD section) Tags: byovd, vulnerable-driver, msr, kernel-mode, lpe, signed-driver

Summary

LnvMSRIO.sys is a Lenovo-signed kernel driver shipped with management tooling. It registers a device named WinMsrDev with no DACL, so any local process — including a low-IL one — can open a handle and call IOCTLs. Four of those IOCTLs expose arbitrary __rdmsr / __wrmsr and arbitrary physical memory read/write via MmMapIoSpace. From a low-priv process, this is straight-line ring-0 code execution.

The exploit is interesting in two ways: it doesn’t need a memory-corruption bug — the driver itself is the primitive — and it doesn’t go through IORING / WNF / token-steal at all. Instead it overwrites the LSTAR MSR with a ROP gadget, traps a syscall, and runs shellcode in CPL=0 directly.

The IOCTLs

No bounds checks, no caller validation — purely “do what the IOCTL says”.

Exploitation

1. Open the device — CreateFileA("\\\\.\\WinMsrDev", ...).
2. Read LSTAR (MSR 0xC0000082) → leaks the address of KiSystemCall64.
3. Compute kernel base by subtracting the static offset of KiSystemCall64 within ntoskrnl.exe.
4. Locate ROP gadgets in the running ntoskrnl image — gadgets to clear SMEP in CR4 and to swap stacks.
5. Stage shellcode in user space:
   • disable SMEP (CR4 &= ~SMEP_BIT)
   • find PID 4 (System), copy its _TOKEN onto the calling process
   • restore LSTAR to the original KiSystemCall64
6. Write LSTAR with the address of the first ROP gadget (__wrmsr IOCTL).
7. Trigger a syscall. The CPU jumps to the attacker-controlled gadget at CPL=0 — shellcode runs, token is swapped, LSTAR restored, the process returns to user mode as SYSTEM.

Why BYOVD matters

LnvMSRIO.sys is signed by a Microsoft-trusted certificate chain (vendor pre-load), so it loads on default-policy Windows. The BYOVD pattern is: an attacker who has some code execution drops a known-vulnerable driver, loads it (legitimately, since it’s signed), then talks to it for kernel R/W.

Microsoft’s Vulnerable Driver Block List catches known offenders, but the cadence lags — operators routinely use newly-disclosed drivers in the days/weeks before block-list updates ship. LnvMSRIO.sys may or may not be on the block list at any given time.

For defenders, the lever is HVCI (Memory Integrity): with HVCI on, unsigned-but-loaded vulnerable drivers can still expose primitives, but kernel-side exploitation becomes harder and detection telemetry improves.

Detection

• Driver loads of LnvMSRIO.sys on hosts that aren’t running Lenovo management software.
• CreateFile("\\.\WinMsrDev") from non-Lenovo processes.
• LSTAR-MSR writes from outside expected boot sequences (deeply unusual).

References

• Luis Casvella (Quarkslab) — BYOVD to the next level (part 1) — exploiting a vulnerable driver (CVE-2025-8061) — https://blog.quarkslab.com/exploiting-lenovo-driver-cve-2025-8061.html
• Microsoft — Vulnerable Driver Block List — https://learn.microsoft.com/en-us/windows/security/application-security/application-control/windows-defender-application-control/design/microsoft-recommended-driver-block-rules
• See also: Mitigations — HVCI / VBS / Driver Signature Enforcement