Description

PassMark PerformanceTest before 11.1 build 1012, BurnInTest before 11.1 build 1000, and OSForensics before 11.1 build 1016 contain an unauthenticated physical memory disclosure in DirectIo64.sys, reachable by unprivileged local users through a single IOCTL with no caller-identity check. The handler writes a crash-dump-format (PAGEDU64) image of all physical memory to a caller-supplied file path in the SYSTEM context, allowing a standard user to create files in locations they cannot otherwise write and to recover memory belonging to processes of other users. The image is preceded by a header that exposes the kernel loaded-module list, active-process list and PFN database pointers, defeating KASLR. The same handler also dereferences the return value of an internal kernel-structure locator without a NULL check; that locator returns NULL on three distinct failure paths, and a kernel crash results on builds where any of those paths is taken.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.1",
  "pubDate": "2026-09-04T19:17:28.710Z",
  "pubdate": "2026-09-04T19:17:28.710Z",
  "executiveSummary": "A critical vulnerability exists in PassMark PerformanceTest (before 11.1 build 1012), BurnInTest (before 11.1 build 1000), and OSForensics (before 11.1 build 1016) due to an improper access control flaw in the DirectIo64.sys kernel driver.\nThe vulnerability manifests as an unauthenticated physical memory disclosure, allowing unprivileged local users to trigger the driver to dump the entire contents of system physical memory into an arbitrary file path.\nBecause the write operation occurs within the SYSTEM security context, an attacker can bypass file system access controls to create files in restricted directories.\nFurthermore, the generated crash-dump-format (PAGEDU64) file contains sensitive kernel metadata, including the kernel module list, active process lists, and PFN database pointers, effectively neutralizing Kernel Address Space Layout Randomization (KASLR).\nBeyond data exfiltration, the driver fails to perform necessary NULL pointer validation on an internal kernel-structure locator function, which can be exploited to trigger a kernel crash (Blue Screen of Death).\nThis vulnerability requires local access but grants standard users administrative-level visibility and potential for privilege escalation by leveraging the disclosure of sensitive kernel structures.",
  "technicalDetails": "The vulnerability resides within the DirectIo64.sys driver used by various PassMark software suites. The driver exposes a control interface that accepts IOCTL requests from user-mode applications. A specific IOCTL handler is incorrectly implemented, lacking proper caller-identity validation or access control checks, enabling unprivileged local processes to invoke privileged operations.\nUpon receiving the malicious IOCTL request, the driver interprets a caller-supplied file path and initiates a write operation to save a full physical memory image in the PAGEDU64 crash-dump format. Because this operation is executed by the driver in the SYSTEM context, the security descriptors of the target file path are ignored, allowing for arbitrary file creation and potential data overwriting in locations normally protected from standard users.\nThe memory dump generated is comprehensive, capturing the entire physical address space. Crucially, the file header includes metadata structures such as the kernel loaded-module list, the active-process list, and pointers to the Page Frame Number (PFN) database. Access to this information provides an attacker with the exact memory offsets required to calculate kernel base addresses, rendering KASLR ineffective. This information is a prerequisite for developing reliable kernel-level exploits that bypass modern OS security protections.\nA secondary flaw exists within the same IOCTL handler regarding internal kernel-structure lookup. The driver calls an internal locator function that is prone to returning NULL under three specific error conditions. The driver fails to check the returned pointer before dereferencing it. If an attacker identifies the conditions required to trigger these failure paths, they can force an illegal memory access, resulting in a system-wide kernel panic.\nThe attack flow proceeds as follows: 1) An attacker crafts a malicious IOCTL request directed at the DirectIo64.sys device object. 2) The attacker passes a chosen file path as part of the request buffer. 3) The driver executes the handler, bypassing all authorization checks. 4) The driver writes a full memory dump to the specified path, capturing kernel-mode structures and process memory from all users. 5) The attacker parses the dump to exfiltrate secrets or recover KASLR base addresses to facilitate further exploitation. 6) Optionally, the attacker provides input designed to trigger the identified NULL pointer dereference, leading to a denial-of-service condition via system crash."
}