Description

PassMark PerformanceTest before 11.1 build 1012, BurnInTest before 11.1 build 1000, and OSForensics before 11.1 build 1016 contain a privilege escalation vulnerability in DirectIo64.sys that allows local users to issue arbitrary IN and OUT instructions to any x86 I/O port due to missing allowlist or port validation on exposed IOCTLs. Attackers can obtain a device handle and write to sensitive ports including the PS/2 controller port, CPU reset ports, CMOS configuration ports, and interrupt controller ports to cause an immediate system reset or other hardware-level manipulation from a standard user account.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.1",
  "pubDate": "2026-09-04T19:17:28.560Z",
  "pubdate": "2026-09-04T19:17:28.560Z",
  "executiveSummary": "A privilege escalation vulnerability exists in the DirectIo64.sys kernel-mode driver utilized by PassMark PerformanceTest, BurnInTest, and OSForensics.\nThe vulnerability originates from inadequate validation of input/output control (IOCTL) requests, allowing unprivileged local users to perform arbitrary IN and OUT instructions against any x86 hardware port.\nBy bypassing software-based security boundaries, an attacker with local access can gain unauthorized interaction with critical hardware components.\nThe impact includes system-wide instability, hardware manipulation, and potential denial-of-service via system reset commands.\nAffected products include PassMark PerformanceTest prior to 11.1 build 1012, BurnInTest prior to 11.1 build 1000, and OSForensics prior to 11.1 build 1016.\nSuccessful exploitation requires no prior elevated privileges, meaning a standard user account is sufficient to achieve kernel-level I/O access.\nThe risk to the host environment is severe, as the vulnerability facilitates direct interaction with sensitive hardware resources such as the CMOS, PS/2 controllers, and interrupt controllers, bypassing standard operating system access controls.",
  "technicalDetails": "The vulnerability resides within the DirectIo64.sys driver, a kernel-mode component designed to facilitate low-level hardware diagnostics for the affected PassMark software suite.\nThe root cause is a lack of rigorous input validation and the absence of an allowlist for the IOCTL interface exposed to user-mode applications.\nSpecifically, the driver fails to restrict the range of I/O ports accessible via its exposed IOCTLs, enabling a user-mode process to supply arbitrary port addresses and values for standard x86 IN and OUT instructions.\nUnder normal circumstances, access to hardware I/O ports is highly restricted by the Windows kernel to prevent user-mode processes from interfering with core system stability or security.\nThe attack flow begins when an unprivileged local user opens a handle to the vulnerable device object created by DirectIo64.sys. Once the handle is acquired, the attacker can transmit crafted IOCTL requests that are processed by the driver without performing any security checks against the requested port or the requested operation.\nThe driver acts as a proxy, executing the privileged I/O instructions on behalf of the unprivileged requester.\nThis allows the attacker to interact directly with hardware at the bus level. Examples of sensitive targets include the PS/2 controller (Port 0x60/0x64), which can be manipulated to interact with keyboard and mouse input or reset the system; CMOS configuration ports, which store BIOS settings; and the Programmable Interrupt Controller (PIC), which manages hardware interrupts.\nBy writing to CPU reset ports or specific control registers, an attacker can induce an immediate hardware-level system reset, resulting in a denial-of-service state.\nBecause the operation occurs within the context of the DirectIo64.sys driver running at kernel privilege levels (Ring 0), the security boundary normally enforced by the CPU and the OS for user-mode processes (Ring 3) is entirely bypassed.\nThe exploitation does not require special administrative privileges; however, it is constrained to local access, as the device interface is typically not exposed over network protocols. The persistence of the risk is contingent upon the driver remaining active on the host system."
}