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

The DxgkDdiEscape handler for 0x5000027 accepts a user provided pointer,
but does no checks on it before using it.

...
    DWORD* user_ptr = escape_5000027_data->user_ptr;
    v32 = user_ptr[2];
    v33 = user_ptr + 3;
    if ( v32 != -1 )
        v33 = (_DWORD *)v32;
    sub_91C24(miniport_context_, *user_ptr, user_ptr[1], v33, (__int64)&escape_data_);
...

The PoC I’ve provided causes a read on said pointer, but based on inspecting where this pointer
is passed it seems like there is at least 1 code path that can result in a write (I haven't
confirmed this though). 

(On Win 10 x64 with 372.54)

FAULTING_IP: 
nvlddmkm!nvDumpConfig+1338c7
fffff801`8a26a79f 8b4808          mov     ecx,dword ptr [rax+8]

CONTEXT:  ffffd00023649970 -- (.cxr 0xffffd00023649970)
rax=4141414141414141 rbx=ffffd0002364a870 rcx=0000000005000017
rdx=ffffd0002364a498 rsi=0000000000000000 rdi=ffffd0002364a498
rip=fffff8018a26a79f rsp=ffffd0002364a390 rbp=ffffd0002364a4a9
 r8=ffffd0002364a870  r9=ffffe8023c537220 r10=0000000000000000
r11=ffffd0002364a370 r12=ffffe8023c537220 r13=fffff80189fa9370
r14=ffffe000d6f2a000 r15=ffffe8023c537220
iopl=0         nv up ei pl zr na po nc
cs=0010  ss=0018  ds=002b  es=002b  fs=0053  gs=002b             efl=00010246
nvlddmkm!nvDumpConfig+0x1338c7:
fffff801`8a26a79f 8b4808          mov     ecx,dword ptr [rax+8] ds:002b:41414141`41414149=????????
Resetting default scope

To reproduce, compile PoC 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/40663.zip