CVE-2025-67246: Ludashi Driver Information Disclosure Flaw

CVE-2025-67246 Overview

A local information disclosure vulnerability has been identified in the Ludashi driver before version 5.1025. The vulnerability stems from a lack of access control in the IOCTL handler, which exposes a device interface accessible to normal users. The driver handles attacker-controlled structures containing the lower 4GB of physical addresses and maps arbitrary physical memory via MmMapIoSpace, copying data back to user mode without verifying the caller's privileges or the target address range.

This vulnerability allows unprivileged users to read arbitrary physical memory, potentially exposing kernel data structures, kernel pointers, security tokens, and other sensitive information. The impact extends beyond simple information disclosure, as the vulnerability can be leveraged to bypass Kernel Address Space Layout Randomization (KASLR) and achieve local privilege escalation.

Critical Impact

Unprivileged local attackers can read arbitrary physical memory, exposing kernel data structures and security tokens, potentially leading to KASLR bypass and local privilege escalation.

Affected Products

• Ludashi driver versions before 5.1025

Discovery Timeline

• 2026-01-15 - CVE CVE-2025-67246 published to NVD
• 2026-01-16 - Last updated in NVD database

Technical Details for CVE-2025-67246

Vulnerability Analysis

The vulnerability exists in the Ludashi Windows kernel driver's IOCTL handler implementation. When processing I/O control requests, the driver fails to implement proper access control checks, allowing any local user—regardless of privilege level—to interact with the exposed device interface.

The core issue lies in how the driver processes user-supplied physical address parameters. An attacker can craft a malicious IOCTL request containing arbitrary physical memory addresses within the lower 4GB address range. The driver then uses the Windows kernel function MmMapIoSpace to map these physical addresses into kernel virtual address space and subsequently copies the contents to a user-mode buffer.

The absence of privilege verification or address range validation means that sensitive kernel memory regions, including process tokens, kernel pointers, and internal data structures, become accessible to unprivileged processes. This type of vulnerability is particularly dangerous as it provides attackers with the foundational information needed to construct more sophisticated attacks.

Root Cause

The root cause is improper privilege management (CWE-269) in the driver's IOCTL handler. The driver exposes a device object accessible to standard user accounts without implementing mandatory access control checks. Additionally, the handler accepts physical addresses from user mode without validating whether the caller should have access to those memory regions. The direct use of MmMapIoSpace to map user-controlled physical addresses, combined with unrestricted data copy operations to user-mode buffers, creates a classic arbitrary memory read primitive.

Attack Vector

The attack vector is local, requiring an attacker to have access to execute code on the target system. The attacker must:

1. Open a handle to the vulnerable Ludashi driver's device object
2. Craft an IOCTL request with a malicious input buffer containing target physical addresses
3. Send the request to the driver and receive the copied physical memory contents in the output buffer

The vulnerability exploitation mechanism involves the driver's IOCTL handler accepting user-controlled structures containing physical address specifications. Upon receiving such a request, the driver maps the specified physical memory range using MmMapIoSpace and copies the contents to the user-supplied output buffer. Since no privilege checks or address validation occurs, an attacker can systematically read physical memory to locate kernel base addresses (defeating KASLR), extract process tokens for privilege escalation, or gather other sensitive kernel information.

For detailed technical information, refer to the GitHub CVE Publication Repository and the Ludashi Security Resource.

Detection Methods for CVE-2025-67246

Indicators of Compromise

• Unusual access patterns to Ludashi driver device objects from non-administrative processes
• Processes making repeated IOCTL calls to the Ludashi driver with varying physical address parameters
• Unexpected memory mapping operations originating from the Ludashi driver
• Evidence of KASLR bypass attempts or kernel address leakage in process memory

Detection Strategies

• Monitor for suspicious IOCTL communications with the Ludashi driver from unprivileged processes
• Implement driver-level monitoring to detect MmMapIoSpace calls with addresses outside expected operational ranges
• Deploy endpoint detection rules to identify processes attempting to enumerate kernel memory regions
• Use behavioral analysis to detect privilege escalation attempts following driver interaction

Monitoring Recommendations

• Enable detailed Windows kernel auditing for device object access and IOCTL operations
• Configure SentinelOne to monitor for suspicious driver interactions and privilege escalation patterns
• Implement alerting for any processes accessing the Ludashi driver device that are not part of normal Ludashi application operations
• Review system logs for evidence of kernel memory information disclosure or KASLR bypass indicators

How to Mitigate CVE-2025-67246

Immediate Actions Required

• Update the Ludashi driver to version 5.1025 or later immediately
• Restrict access to the vulnerable driver by limiting device object permissions to administrative users only
• Consider temporarily disabling or uninstalling the Ludashi driver until the patched version can be deployed
• Audit systems for any indicators of prior exploitation

Patch Information

Update to Ludashi driver version 5.1025 or later, which addresses this vulnerability. Check the Ludashi Security Resource for the latest driver version and update instructions. The patch implements proper access control checks in the IOCTL handler to prevent unauthorized physical memory reads.

Workarounds

• Restrict access to the Ludashi driver's device object by modifying the device's security descriptor to only allow access from SYSTEM and Administrators
• Remove or disable the Ludashi driver if it is not required for business operations
• Implement application whitelisting to prevent unauthorized processes from interacting with the driver
• Deploy network segmentation to limit the impact of potential privilege escalation

# Restrict device access to administrators only (PowerShell)
# Note: Device path may vary; adjust as needed for your environment
$devicePath = "\\.\LudashiDriver"
# Review and restrict driver permissions through driver configuration or Group Policy
# Consider disabling driver loading until patched version is available
sc.exe config LudashiDriver start= disabled