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 modify hardware configuration by exploiting exposed IOCTLs with no validation on device selection, register offset, or value. Attackers can obtain a device handle and issue arbitrary PCI configuration space read/write operations to enable Bus Master DMA on any PCI device, halt storage controller I/O by clearing command registers, or remap Base Address Registers to redirect DMA to an attacker-chosen physical address.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.8",
  "pubDate": "2026-09-04T19:17:28.420Z",
  "pubdate": "2026-09-04T19:17:28.420Z",
  "executiveSummary": "This vulnerability is an improper access control flaw within the DirectIo64.sys kernel-mode driver, impacting PassMark PerformanceTest (before 11.1 build 1012), BurnInTest (before 11.1 build 1000), and OSForensics (before 11.1 build 1016).\nThe vulnerability manifests as an unauthenticated, unrestricted IOCTL interface that permits local users to perform arbitrary read and write operations on PCI configuration space.\nBy bypassing input validation for device selection, register offsets, and write values, an attacker can manipulate hardware registers, facilitate DMA-based memory corruption, or disrupt system stability by clearing device command registers.\nThe risk is critical, as it grants a local user the ability to escalate privileges, gain kernel-level control over hardware peripherals, and potentially bypass OS security boundaries through DMA redirection or hardware-level denial-of-service.",
  "technicalDetails": "The vulnerability resides within the DirectIo64.sys driver, which exposes insecure Input/Output Control (IOCTL) codes to user-mode processes without implementing adequate security checks or validation mechanisms.\nThe driver fails to perform context-aware filtering on the requested PCI device identifiers, register offsets, or the data payloads transmitted via the IOCTL interface. Because these IOCTLs are accessible by any local user, the driver functions as a primitive that bridges the user-mode/kernel-mode boundary, allowing unprivileged processes to interact directly with hardware configuration registers.\nExploitation follows a sequential attack flow: First, an attacker obtains a valid handle to the device via a standard CreateFile call to the driver's device object. Second, the attacker crafts a malicious IOCTL request, specifying target PCI bus, device, and function identifiers, alongside the desired register offsets. Because the driver performs no validation on the device selection or the nature of the write operation, the driver completes these requests with kernel-level authority.\nThe functional impact of this unauthorized access is severe. An attacker can write to the Command Register of a PCI device to disable its Bus Master DMA capabilities or, conversely, enable DMA on a device where it was previously disabled. By remapping Base Address Registers (BARs), an attacker can redirect DMA transactions to arbitrary physical memory addresses, potentially overwriting kernel memory structures or sensitive data buffers.\nFurthermore, the ability to halt storage controller I/O by clearing command registers allows an attacker to induce a state of kernel instability or facilitate a persistent Denial-of-Service condition. As the driver processes these requests at the kernel privilege level (CPL 0), the vulnerability bypasses standard Windows hardware abstraction layer protections, effectively granting the attacker the ability to reconfigure the system’s hardware topology. This vulnerability is restricted to local exploitation, requiring an attacker to already possess the ability to execute code on the host machine; however, it provides a direct path for privilege escalation from a low-integrity process to kernel-mode code execution."
}