DxgkDdiEscape handler for 0x600000D leads to kernel memory corruption

vendor:

N/A

by:

Project Zero

7,8

CVSS

HIGH

Kernel Memory Corruption

119

CWE

Product Name: N/A

Affected Version From: Win 10 x64 372.54

Affected Version To: Win 10 x64 372.54

Patch Exists: YES

Related CWE: N/A

CPE: N/A

Metasploit: N/A

Other Scripts: N/A

Tags: N/A

CVSS Metrics: N/A

Nuclei References: N/A

Nuclei Metadata: N/A

Platforms Tested: Windows

2016

DxgkDdiEscape handler for 0x600000D leads to kernel memory corruption

The DxgkDdiEscape handler for 0x600000D passes an unchecked user provided pointer as the destination for a memcpy call, leading to kernel memory corruption. The PoC requires WDK for D3DKMTEscape and can be reproduced by compiling the PoC as a x64 binary and running it. 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.

Mitigation:

Ensure that user-provided pointers are checked before being used as the destination for a memcpy call.

Source

Exploit-DB raw data:

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