Description

PassMark PerformanceTest before 11.1 build 1012, BurnInTest before 11.1 build 1000, and OSForensics before 11.1 build 1016 contain an improper access control vulnerability in the DirectIo64.sys kernel driver that allows unprivileged local users to perform privileged hardware operations by opening a handle to the device object created without a security descriptor. Attackers can issue IOCTLs through the permissive default Windows ACL applied to the device to access restricted hardware operations regardless of privilege or integrity level.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.8",
  "pubDate": "2026-09-04T19:17:27.823Z",
  "pubdate": "2026-09-04T19:17:27.823Z",
  "executiveSummary": "The DirectIo64.sys kernel driver, utilized by PassMark PerformanceTest, BurnInTest, and OSForensics, contains an improper access control vulnerability. This flaw stems from the device object being created without a restrictive security descriptor, leading to a permissive default Windows Access Control List (ACL).\nThis vulnerability allows unprivileged local users to interface directly with the kernel driver. By opening a handle to the exposed device object, an attacker can issue arbitrary Input/Output Control (IOCTL) codes to perform restricted hardware operations. This bypasses standard privilege and integrity level enforcement mechanisms.\nThe risk is significant as it provides a pathway for local privilege escalation or unauthorized hardware-level interaction. Successful exploitation requires local access to the system, but does not necessitate prior elevated administrative privileges. Impact includes unauthorized access to system resources and potential kernel-mode execution, compromising the integrity and security of the affected host.",
  "technicalDetails": "The root cause of this vulnerability is the insecure creation of the device object within the DirectIo64.sys driver. When the driver initializes, it fails to specify a Security Descriptor (SD) during the device object creation process, typically via the IoCreateDevice function. In the Windows kernel environment, omitting an explicit security descriptor results in the device object inheriting a default Discretionary Access Control List (DACL).\nIn many legacy or misconfigured driver implementations, this default DACL grants broad 'Generic Read' and 'Generic Write' permissions to the 'Authenticated Users' group or even the 'Everyone' group. Because the device object is exposed to the local user namespace, any unprivileged process can successfully call the CreateFileA or CreateFileW Win32 APIs to obtain a handle to the device path associated with DirectIo64.sys.\nOnce a valid handle is obtained, the attacker can leverage the DeviceIoControl function to communicate directly with the driver. The driver likely exports a set of IOCTLs designed for diagnostic or low-level hardware benchmarking. If these IOCTLs are not properly validated or restricted by the driver's dispatch routines, an attacker can craft malicious request buffers to trigger unauthorized functionality. This includes direct port I/O, reading from or writing to arbitrary physical memory addresses, or interacting with Model-Specific Registers (MSRs).\nThe attack flow proceeds as follows: 1) The attacker identifies the exposed device name (e.g., \\\\.\\DirectIo64). 2) The attacker opens a handle to this device using standard Windows API calls without requiring elevated integrity. 3) The attacker identifies the specific IOCTL codes and associated buffer structures through reverse engineering of the driver binary. 4) The attacker dispatches a specially crafted IOCTL request to the driver. 5) The driver, running at Kernel Mode (Ring 0), processes the request and executes the hardware operation on behalf of the unprivileged process, effectively bypassing the Windows security boundary between User Mode (Ring 3) and Kernel Mode.\nAffected products and versions include: PassMark PerformanceTest before 11.1 build 1012, BurnInTest before 11.1 build 1000, and OSForensics before 11.1 build 1016. The vulnerability is strictly local, requiring the attacker to have interactive or remote interactive access to the target system. Post-exploitation impact may range from information disclosure to full system compromise through kernel-level code execution."
}