The DxgkDdiEscape handler for escape code 0x100010b looks like:
char escape_100010b(NvMiniportDeviceContext *miniport_context, HANDLE handle, unsigned int idx)
{
PVOID *Object;
if ( !handle )
do_debug_thingo();
Object = (PVOID *)&miniport_context->UNKNOWN[8 * idx + 22696];
if ( !ObReferenceObjectByHandle(handle_, SYNCHRONIZE, )ExEventObjectType, UserMode, Object, 0i64) )
{
result = 0;
if ( *Object )
result = UserMode;
}
return result;
}
It essentially takes in a user mode event handle from userspace, and calls
ObReferenceObjectByHandle on it, writing the object pointer to |Object|. Note
that the kernel implementation of ObReferenceObjectByHandle always begins with
writing NULL to this pointer regardless of whether or not the handle is valid.
|Object| is calculated using a user provided index that is not bounds checked,
leading to OOB write of either NULL or the KEVENT pointer:
Object = (PVOID *)&miniport_context_->UNKNOWN[8 * idx + 22696];
The attached PoC causes the following crashing context on Win x64 372.54:
PAGE_FAULT_IN_NONPAGED_AREA (50)
...
rax=ffffe0025ea28f50 rbx=0000000000000000 rcx=0000000000000000
rdx=0000000000100000 rsi=0000000000000000 rdi=0000000000000000
rip=fffff801d8f3daf5 rsp=ffffd000203deda0 rbp=0000000000000001
r8=ffffe000506d4b50 r9=ffffe000524fb201 r10=0000000000000000
r11=ffffd000203df370 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei pl zr na po nc
nt!ObReferenceObjectByHandleWithTag+0x45:
fffff801`d8f3daf5 488908 mov qword ptr [rax],rcx ds:ffffe002`5ea28f50=????????????????
To reproduce, compile as a x64 executable and run (requires WDK for D3DKMTEscape).
This bug is subject to a 90 day disclosure deadline. If 90 days elapse
without a broadly available patch, then the bug report will automatically
become visible to the public.
