CVE-2026-80115 in PerformanceTest
Summary
by MITRE • 09/04/2026
PassMark PerformanceTest before 11.1 build 1012, BurnInTest before 11.1 build 1000, and OSForensics before 11.1 build 1016 contain a privilege escalation and denial-of-service vulnerability in DirectIo64.sys that allows local attackers to read arbitrary Model-Specific Registers or write zero to any MSR through exposed IOCTLs with insufficient blocklist enforcement. Attackers can exploit the unrestricted write IOCTL to zero out the system call handler MSR, causing an immediate unrecoverable kernel crash on the next system call, or read security-sensitive MSRs used to locate kernel data structures.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/04/2026
The vulnerability identified in PassMark PerformanceTest prior to version 11.1 build 1012, BurnInTest prior to version 11.1 build 1000, and OSForensics prior to version 11.1 build 1016 centers on a critical flaw within the DirectIo64.sys driver component. This issue stems from insufficient enforcement of blocklists for Input/Output Control codes, commonly referred to as IOCTLs, which are used by user-mode applications to communicate with kernel-mode drivers. The core technical deficiency lies in the lack of rigorous validation and access control checks when handling these IOCTL requests. Specifically, the driver exposes functionality that allows local attackers to interact directly with Model-Specific Registers (MSRs) without adequate privilege verification or scope limitation. This architectural oversight creates a pathway for unauthorized manipulation of low-level hardware state variables that are typically restricted to kernel-mode execution contexts.
The operational impact of this vulnerability is severe and multifaceted, encompassing both confidentiality breaches and availability disruptions through denial-of-service attacks. On the confidentiality front, attackers can exploit unrestricted read IOCTLs to access arbitrary Model-Specific Registers. These registers often contain sensitive information such as addresses of critical kernel data structures, security feature states, or other system-level metadata that is not intended for user-mode consumption. By reading these values, a local attacker can gain insights into the internal workings of the operating system, potentially facilitating further exploitation steps like kernel address space layout randomization bypasses or targeted privilege escalation attacks against specific subsystems.
Regarding availability and integrity, the vulnerability allows attackers to write zero to any MSR through exposed IOCTLs with insufficient blocklist enforcement. This capability is particularly dangerous when targeting MSRs associated with system call handlers. By writing a value of zero to these critical registers, an attacker can effectively disable or corrupt the mechanism by which user-mode applications invoke kernel services. When the operating system attempts to execute its next system call, it encounters this corrupted state, leading to an immediate and unrecoverable kernel panic or crash. This results in a complete denial-of-service condition for all users on the affected machine, as the system becomes unresponsive and requires a hard reset to recover.
From a classification perspective, this vulnerability aligns with CWE-284 Improper Access Control, specifically regarding insufficient restrictions applied to critical operations within kernel drivers. The ability to read arbitrary MSRs also maps closely to CWE-755 Improper Handling of Exceptional Conditions if it leads to crashes, but more accurately reflects the unauthorized access aspects defined in CWE-269 Improvement of Privileges or CWE-134 Use of Externally-Controlled Format String if interpreted broadly as uncontrolled resource usage. In terms of offensive security frameworks such as MITRE ATT&CK, this vulnerability supports techniques related to System Information Discovery (T1082) for reading MSRs and potentially contributes to Denial of Service via system instability or kernel exploitation paths often associated with privilege escalation chains like T1068 Exploitation for Privilege Escalation.
Mitigation strategies primarily involve updating the affected software components to versions that address these IOCTL handling flaws. Users should upgrade PassMark PerformanceTest, BurnInTest, and OSForensics to their latest stable releases where blocklist enforcement has been strengthened and input validation mechanisms have been implemented to restrict MSR access to only those operations explicitly required for legitimate functionality. For system administrators managing environments with older versions of this software, it is advisable to apply strict application whitelisting policies or disable the specific driver functionalities if possible until patches are deployed. Additionally, enabling kernel patching protections such as Kernel Patch Protection on supported Windows architectures can provide a layer of defense against certain types of MSR corruption that lead to system crashes, although direct mitigation via vendor updates remains the most effective solution.