Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=927

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).


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/40661.zip