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
