CVE-2025-1533

AsIO3.sys -- stack-based buffer overflow in IRP_MJ_CREATE handler via extended-length path

Summary

Field	Value
Driver	`AsIO3.sys`
Vendor	ASUS
Vulnerability Class	Buffer Overflow (Stack)
TALOS ID	TALOS-2025-2144
Exploited ITW	No
Status	Blocklisted

Affected Functions

Win32PathToNtPath (called from IRP_MJ_CREATE handler)

Root Cause

When Talos researchers examined the ASUS AsIO3 driver, they found a stack buffer overflow hiding in the very first code path any caller hits: the IRP_MJ_CREATE handler, which runs every time a process opens the driver's device object.

The handler calls an internal function, Win32PathToNtPath, to convert the requesting process's path from a Win32 format to an NT path. This function copies the input path into a stack buffer sized at 255 characters, roughly matching the classic MAX_PATH limit of 260 characters. The developers apparently assumed that Windows paths could never exceed this limit.

That assumption is wrong. Windows has supported extended-length paths (prefixed with \\?\) since Windows NT, and these can reach 32,767 characters. The Win32PathToNtPath function performs no length validation before the copy. If an attacker launches a process from a directory path longer than 255 characters, the copy overflows the stack buffer, overwriting the return address and adjacent stack frames.

Vulnerable Code Path

IRP_MJ_CREATE
  --> Win32PathToNtPath
    --> copies caller path into 255-char stack buffer (no length check)
    --> stack buffer overflow

Exploitation

The overflow gives classic stack-based control: the attacker overwrites the return address on the kernel stack, redirecting execution when the function returns. Combined with the authorization bypass in CVE-2025-3464 (which is needed to reach the vulnerable code path in the first place), this creates a viable chain for kernel code execution.

In practice, the Talos researchers did not use CVE-2025-1533 in their final exploit chain. They found the driver's existing IOCTL primitives more convenient after bypassing authorization through CVE-2025-3464. But the stack overflow remains a viable alternative entry point for attackers who prefer traditional stack smashing over IOCTL-based exploitation.

Exploitation Primitive

Process with extended-length path (>255 chars) opens AsIO3 device
  --> stack buffer overflow in Win32PathToNtPath
  --> return address overwrite --> kernel code execution

Patch Analysis

The fix is to add length validation in Win32PathToNtPath that rejects paths exceeding the stack buffer size before the copy operation begins.

Detection

YARA Rule

rule CVE_2025_1533_AsIO3 {
    meta:
        description = "Detects AsIO3.sys versions vulnerable to stack overflow in Win32PathToNtPath"
        cve = "CVE-2025-1533"
        author = "KernelSight"
        severity = "high"
    strings:
        $mz = { 4D 5A }
        $driver_name = "AsIO3" wide ascii nocase
        $func = "Win32PathToNtPath" ascii
    condition:
        $mz at 0 and $driver_name and $func
}

Behavioral Indicators

Process with extended-length path (>260 characters) attempting to open AsIO3.sys device
Stack corruption / bugcheck following IRP_MJ_CREATE to AsIO3 device

Techniques Used

Technique	KernelSight Page
Stack Buffer Overflow	Buffer Overflow

Broader Significance

CVE-2025-1533 is a reminder that attack surface is not limited to IOCTL handlers. The IRP_MJ_CREATE handler runs before any authorization check, before any IOCTL dispatch, simply by opening the device. When that handler trusts input lengths, even something as mundane as a process path becomes an exploitation vector. The MAX_PATH assumption, debunked for decades, continues to produce real vulnerabilities in production drivers.