CVE-2025-51619 in DPC Latency Checker
Summary
by MITRE • 09/09/2026
A vulnerability in the Thesycon DPC Latency Checker driver (dpc.sys) thru 1.4.0 allows local unprivileged users to cause a denial-of-service (BSOD) condition on Windows systems. The driver exposes an IOCTL interface (0x81772008) that accepts user-controlled input without validating pointers before passing them to kernel APIs. Specifically, it dereferences a user-supplied pointer and uses the resulting value in a call to ExSetTimerResolution, leading to an arbitrary kernel memory access. Exploiting this flaw results in a system crash.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/09/2026
The vulnerability identified within the Thesycon DPC Latency Checker driver, specifically versions up through 1.4.0, represents a critical security flaw rooted in improper input validation and unsafe pointer dereferencing within the Windows kernel environment. This issue affects local unprivileged users who can interact with the device interface exposed by dpc.sys to trigger a denial-of-service condition resulting in a Blue Screen of Death (BSOD). The core technical deficiency lies in the handling of an Input/Output Control code, specifically 0x81772008. When this IOCTL is invoked, the driver fails to perform adequate validation on user-supplied pointers before attempting to utilize them within kernel-mode operations. This lack of sanitization allows a malicious actor with local access to supply arbitrary memory addresses or invalid pointer values that are subsequently processed by sensitive kernel APIs without any checks for validity, accessibility, or proper privilege levels.
The operational mechanism of the exploit involves the driver directly dereferencing a user-controlled pointer and passing the resulting value into the ExSetTimerResolution function. This API call is designed to adjust system timer resolution but requires valid memory references and appropriate context. By supplying an invalid or maliciously crafted pointer, the attacker forces the kernel to access arbitrary physical or virtual memory locations that are not mapped for such operations or do not belong to the current process context. This action violates fundamental operating system security boundaries, leading to a fault in protected mode execution. The immediate consequence is a critical system error that halts all processing on the affected Windows host, resulting in an automatic restart and potential data loss if unsaved work was present at the time of exploitation.
From a classification perspective, this vulnerability aligns with CWE-125, Out-of-bounds Read, as it involves accessing memory outside of intended boundaries due to unchecked pointer usage. It also reflects aspects of CWE-94, Improper Control of Generation of Code (Code Injection), in the broader sense that arbitrary code execution paths are triggered through kernel faults, although the primary impact here is denial of service rather than remote code execution. In terms of adversary behavior mapping under the MITRE ATT&CK framework, this flaw facilitates Local Privilege Escalation techniques where an attacker might use the resulting crash to disrupt availability or potentially leverage subsequent crashes for further exploitation attempts against other system components. The attack vector requires local access, meaning it is categorized as a low-complexity vulnerability for any user account on the target machine that has permission to open and interact with the device driver interface.
Mitigation strategies must focus on both immediate remediation and long-term architectural improvements. The most effective solution is to update the Thesycon DPC Latency Checker software to version 1.4.1 or later, where the vendor has presumably implemented proper validation checks for pointer arguments before they are passed to kernel functions like ExSetTimerResolution. For organizations unable to immediately patch this specific driver, restricting access to the device interface via Windows Device Guard policies or AppLocker rules can prevent unprivileged users from invoking the vulnerable IOCTL code 0x81772008. Additionally, enabling Kernel Patch Protection and ensuring that kernel debugging symbols are not exposed in production environments can help mitigate some secondary risks associated with such memory corruption flaws. Regular auditing of installed third-party drivers for known vulnerabilities is also recommended to maintain a secure endpoint posture against local denial-of-service attacks.