Overview
Analyzing CVE‑2025‑0287: From IOCTL Entry to Arbitrary Kernel Memory Write … in driver biontdrv.sys
In this post, I document the technical analysis of a vulnerability affecting the BioNTDrv.sys Windows kernel driver, associated with CVE‑2025‑0287 and CVE‑2025‑0288. The goal of this analysis is not to present a full exploit, but rather to examine whether the reported issue is limited to a denial‑of‑service condition or if it exposes a stronger primitive that could be leveraged for kernel‑mode exploitation.
By combining static analysis using IDA Pro and dynamic analysis with WinDbg, I trace the execution flow of a vulnerable IOCTL handler and evaluate how user‑controlled input is processed inside the kernel. The focus is placed on understanding memory access patterns, validation logic, and the resulting security impact.
During the analysis, special attention was given to how user‑supplied pointers and sizes are handled, as improper validation in kernel drivers often leads to powerful exploitation primitives rather than immediate system crashes.
Locating the Vulnerable IOCTL Handler
The first step in the analysis was identifying how user-mode requests are routed inside the driver. By examining DriverEntry, it becomes clear that BioNTDrv.sys registers a single dispatch routine for multiple IRP major functions.
In particular, the IRP_MJ_DEVICE_CONTROL handler is assigned to the function sub_11280, indicating that all IOCTL requests issued via DeviceIoControl are processed through this routine.
DriverEntry showing registration of the IRP_MJ_DEVICE_CONTROL dispatch routine
To confirm the static findings, the driver object was inspected at runtime using WinDbg. The output of !drvobj confirms that IRP_MJ_DEVICE_CONTROL is routed to the same handler observed during static analysis, validating the accuracy of the control flow reconstruction.
Runtime confirmation of IRP_MJ_DEVICE_CONTROL dispatch routine via WinDbg
Analyzing the IOCTL Dispatch Routine
The dispatch routine begins by retrieving the current IO_STACK_LOCATION and validating that the request corresponds to IRP_MJ_DEVICE_CONTROL. All other IRP types are rejected early, confirming that this routine primarily serves as an IOCTL handler.
Instead of using the standard IoControlCode field, the driver interprets the IOCTL selector from Parameters.Read.ByteOffset.LowPart. This unconventional design immediately raises concerns regarding input validation and interface robustness.
Identify the target IOCTL
The IOCTL handler for code 0x220014 maps a user-supplied physical address using MmMapIoSpace and copies the mapped memory into a user-provided buffer using memmove. The only validation performed is a strict check on the input buffer length, while the contents themselves remain entirely user-controlled.
What this IOCTL does:
v8 = InputBufferLength
It just checks if it is equal to 0x10.
There is no other validation on the content.
This means:
User provides physical address
User controls mapping size
Driver maps it
And then:
Very important:
Destination: v7->MdlAddress (user-controlled)
Size: user-controlled
No try/except
No ProbeForWrite/ProbeForRead
No real bounds check
Runtime analysis
After setting a breakpoint on the common dispatch routine, execution was continued until an IRP_MJ_DEVICE_CONTROL request was observed. Runtime inspection of the active IRP confirms that IOCTL 0x220014 is correctly routed to the vulnerable code path, with an input buffer length of 0x10, satisfying the handler’s initial validation check.
Runtime analysis of memmove and exploit primitive validation
This results in a kernel-mode memmove copying data from a kernel-mapped source buffer into a fully user-controlled virtual address.
| Register | ||
|---|---|---|
| RCX | Destination | 0x4141414141414141 |
| RDX | Source | kernel address |
| R8 | Length | 0x300 |
What things don’t exist?
❌ ProbeForWrite
❌ __try / __except
❌ MmCopyVirtualMemory
❌ PreviousMode check
❌ SeAccessCheck
No system crash is required to demonstrate exploitability. The presence of a fully controllable kernel write primitive is sufficient to bypass multiple kernel mitigations under realistic exploitation scenarios.
At the moment of the memmove invocation, runtime inspection confirms that the destination pointer (RCX) resides in the User Probe Area, while the source pointer (RDX) points to a kernel-mapped region. This demonstrates a direct kernel-to-user memory copy without any form of pointer probing or access validation.
Security Impact and Exploitability Analysis
Although triggering IOCTL 0x220014 does not immediately lead to a system crash, runtime analysis reveals a far more critical issue.
As shown during live debugging in WinDbg, the driver performs a memmove operation where the destination pointer (v7->MdlAddress) is fully controlled by user input, while the source buffer originates from a kernel-mapped memory region obtained via MmMapIoSpace.
Crucially, no validation is performed on the destination pointer prior to the copy operation. The driver does not invoke ProbeForWrite, does not check the requestor mode, and does not wrap the operation in structured exception handling. As a result, the kernel blindly trusts a user-supplied address when performing a memory write.
This behavior effectively provides an arbitrary kernel-to-user memory copy primitive. While this primitive alone does not crash the system, such controlled memory operations are commonly leveraged as building blocks in real-world kernel exploitation scenarios, particularly for information disclosure or privilege escalation when combined with additional primitives.
Therefore, the absence of a crash does not reduce the security impact of this vulnerability. On the contrary, the presence of a reliable and attacker-controlled memory copy primitive significantly increases its exploitability.
During debugging, I intentionally supplied an unmapped user-mode address as the destination to observe the driver’s behavior under controlled conditions.
Mitigation Analysis
Despite modern kernel mitigations such as SMEP and user-mode probing mechanisms, the vulnerable code path in this driver bypasses several fundamental security checks.
The IOCTL handler does not validate the requestor mode of the IRP and does not perform any probing on user-supplied pointers prior to invoking memmove. As a result, user-controlled addresses are treated as trusted kernel pointers.
Furthermore, the memory copy operation is executed in kernel context without structured exception handling, making the behavior entirely dependent on the supplied address validity rather than explicit security logic.
Kernel mitigations such as SMEP are not applicable in this scenario, as the vulnerability does not involve instruction pointer control or code execution, but rather an attacker-controlled memory write primitive.
The absence of an immediate system crash should not be interpreted as a lack of security impact. On the contrary, controlled non-crashing primitives are often preferable in real-world exploitation due to their reliability and stealth.
the vulnerable code path executes without invoking any of the relevant kernel-mode mitigations.
Conclusion and Security Impact
This analysis demonstrates that IOCTL 0x220014 in BioNTDrv.sys exposes a kernel-mode memory copy operation that directly consumes user-controlled input without sufficient validation.
Through combined static and dynamic analysis, it was shown that the driver performs a memmove operation using a destination pointer fully controlled by the caller, while executing in kernel context.
Importantly, triggering this behavior does not necessarily result in a system crash.
The absence of a crash should not be interpreted as reduced severity. On the contrary, the ability to perform controlled, non-crashing memory operations in kernel mode is often more desirable from an attacker’s perspective due to improved reliability and stability.
While a full weaponized exploit is not provided, the observed behavior is sufficient to establish meaningful exploitation potential.
Kernel drivers operate on security-critical objects whose integrity directly impacts system trust boundaries. The ability to influence kernel memory operations using attacker-controlled parameters represents a well-known and powerful exploitation primitive.
Modern kernel mitigations such as SMEP do not directly mitigate this issue, as the vulnerability does not rely on instruction pointer control or execution of user-supplied code.
Instead, the vulnerable code path executes a trusted memory copy operation without requestor mode validation, pointer probing, or exception handling, effectively bypassing multiple layers of expected kernel safety checks.
As a result, this vulnerability constitutes a serious violation of kernel trust assumptions and may be leveraged as a building block for more advanced exploitation scenarios, depending on system configuration and object layout
This case highlights how seemingly simple IOCTL handlers can introduce high-impact vulnerabilities when fundamental validation principles are omitted. Even in the absence of an immediate crash, such issues warrant careful scrutiny due to their potential security implications.
Disclosure Notes
This write-up focuses on technical analysis and impact assessment. No exploit code is provided beyond a minimal reproduction proof-of-concept.