1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 |
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<code>8a26a79f 8b4808mov 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=ffffd0002364a870r9=ffffe8023c537220 r10=0000000000000000 r11=ffffd0002364a370 r12=ffffe8023c537220 r13=fffff80189fa9370 r14=ffffe000d6f2a000 r15=ffffe8023c537220 iopl=0 nv up ei pl zr na po nc cs=0010ss=0018ds=002bes=002bfs=0053gs=002b efl=00010246 nvlddmkm!nvDumpConfig+0x1338c7: fffff801</code>8a26a79f 8b4808mov 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 |