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 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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.1",
  "pubDate": "2026-09-04T19:17:28.280Z",
  "pubdate": "2026-09-04T19:17:28.280Z",
  "executiveSummary": "A privilege escalation and denial-of-service vulnerability exists within the DirectIo64.sys kernel-mode driver, utilized by PassMark PerformanceTest, BurnInTest, and OSForensics.\nThe vulnerability stems from insufficient blocklist enforcement within the driver's exposed IOCTL interfaces, allowing local, low-privileged attackers to perform unauthorized read or write operations on Model-Specific Registers (MSRs).\nAn attacker can exploit this flaw to overwrite critical system MSRs—specifically the system call handler MSR—with zero values. This action results in an immediate and unrecoverable kernel panic upon the execution of the next system call, effectively inducing a denial-of-service.\nFurthermore, the ability to read arbitrary MSRs facilitates the leakage of sensitive kernel memory layout information, which can be leveraged to bypass kernel security protections such as KASLR.\nThe vulnerability is restricted to local exploitation, requiring the attacker to execute malicious code on the target host. Given the nature of kernel-mode driver interaction, this flaw poses a severe risk to system stability and integrity, enabling privilege escalation vectors if combined with kernel data structure manipulation.",
  "technicalDetails": "The root cause of the vulnerability resides in the DirectIo64.sys driver's handling of IOCTL requests. The driver exposes interfaces that permit user-mode applications to interface directly with CPU Model-Specific Registers (MSRs) via the RDMSR and WRMSR instructions.\nThe vulnerability is classified as an improper access control issue where the driver lacks robust validation or blocklisting mechanisms for requested MSR addresses. By failing to restrict which MSRs are accessible via these IOCTLs, the driver inadvertently exposes critical CPU configuration registers to non-privileged users.\nThe exploitation flow follows a straightforward pattern: An attacker initializes a handle to the vulnerable DirectIo64.sys driver device object. Once connected, the attacker constructs specially crafted IOCTL requests designed to interact with the MSR space. By invoking the write-oriented IOCTL, the attacker can force the kernel to execute a WRMSR instruction with a user-supplied value. By targeting the MSRs associated with system call entry points (such as the LSTAR register on x64 systems), an attacker can overwrite the pointer to the kernel's system call handler with null bytes.\nUpon the subsequent transition from user-mode to kernel-mode via a syscall instruction, the CPU attempts to jump to the address contained in the corrupted MSR. Since the address is zero, the kernel immediately faults, leading to a BugCheck (BSOD).\nIn addition to the denial-of-service vector, the read-oriented IOCTL allows the attacker to query security-sensitive MSRs. This capability provides a primitive for leaking kernel-mode addresses or locating critical kernel data structures in memory. By analyzing the returned register values, an attacker can determine the base address of the kernel or identify other sensitive offsets required for more complex exploit chains, such as arbitrary kernel memory read/write primitives or bypasses for Kernel Address Space Layout Randomization (KASLR).\nAffected products include PassMark PerformanceTest before 11.1 build 1012, BurnInTest before 11.1 build 1000, and OSForensics before 11.1 build 1016. The vulnerability requires local authentication and standard user privileges to communicate with the driver interface, as no network exposure is inherent to the local IOCTL mechanism itself."
}