Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=911
The DxgkDdiEscape handler for 0x600000D passes an unchecked user provided
pointer as the destination for a memcpy call. This leads to kernel memory
corruption.
(Win 10 x64 372.54) crashing context with PoC:
SYSTEM_SERVICE_EXCEPTION (3b)
CONTEXT: ffffd000c076c8b0 -- (.cxr 0xffffd000c076c8b0)
rax=0000000000000880 rbx=0000000000000000 rcx=000000000000000f
rdx=bebe9ec057cc7d47 rsi=ffffd000c076d870 rdi=ffffe001990da008
rip=fffff8010f1eab00 rsp=ffffd000c076d2d8 rbp=ffffd000c076d360
r8=0000000000003ff1 r9=fffff8010f217d48 r10=fffff78000000008
r11=4141414141414141 r12=0000000000000000 r13=ffffe001990dbe88
r14=ffffe001945f1201 r15=0000000000004000
iopl=0 nv up ei pl nz ac pe nc
cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b efl=00010212
nvlddmkm+0x5dab00:
fffff801`0f1eab00 f3410f7f03 movdqu xmmword ptr [r11],xmm0 ds:002b:41414141`41414141=????????????????????????????????
Resetting default scope
To reproduce, compile the PoC as a x64 binary (requires WDK for D3DKMTEscape),
and run.
For completeness, it looks like many of the other escape handlers in the same function has similar issues with writing to user provided pointers in an unchecked way. This should have been fairly obvious as the code is very close to each other in the same function.
Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/40659.zip
