Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=940 The DxgkDdiEscape handler for 0x70001b2 doesn't do proper bounds checks for its variable size input. void sub_8C4304(...) { ... // escape_->size is controlled by the user. if ( escape_->size < size ) size = escape_->size; memcpy(escape_->data, v31, 28i64 * size); ... } Note that this appears to be a common pattern. Normally, before escape handlers are executed, |PrivateDriverDataSize| (from DXGKARG_ESCAPE) is checked to be equal to some value against a hardcoded table. However, some escapes allow a more relaxed check that |PrivateDriverDataSize| >= minimum. This means that the handler themselves must implement an ad hoc bounds check, which either seems to be missing or implemented incorrectly (relying on a user specified value) in many cases. bug 936 is a similar issue and there are likely more. I've noticed (but not confirmed) a few more OOB reads that I haven't reported that follow this same pattern. Crashing context with PoC (Win 10 x64 with 372.54): PAGE_FAULT_IN_NONPAGED_AREA (50) Invalid system memory was referenced. This cannot be protected by try-except. Typically the address is just plain bad or it is pointing at freed memory. Arguments: ... rax=ffffd000239d51dc rbx=0000000000000000 rcx=fffffffffffffff4 rdx=fffff000e9e6c754 rsi=0000000000000000 rdi=0000000000000000 rip=fffff80166d6aca0 rsp=ffffd000239d3df8 rbp=ffffd000239d3f00 r8=0000000000000924 r9=000000000000003b r10=000000000000e9ef r11=ffffd000239d48ac r12=0000000000000000 r13=0000000000000000 r14=0000000000000000 r15=0000000000000000 iopl=0 nv up ei ng nz ac pe cy nvlddmkm+0x5daca0: fffff801`66d6aca0 f30f7f40f0 movdqu xmmword ptr [rax-10h],xmm0 ds:ffffd000`239d51cc=???????????????????????????????? Resetting default scope To reproduce, compile as an x64 executable an run (requires WDK for D3DKMTEscape). Proof of Concept: https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/40664.zip