Source: https://code.google.com/p/google-security-research/issues/detail?id=506 We have encountered a number of Windows kernel crashes in the win32k.sys driver while processing a specific corrupted TTF font file. The cleanest stack trace we have acquired, which might also indicate where the pool corruption takes place and/or the root cause of the vulnerability, is shown below: --- PAGE_FAULT_IN_NONPAGED_AREA (50) Invalid system memory was referenced. This cannot be protected by try-except, it must be protected by a Probe. Typically the address is just plain bad or it is pointing at freed memory. Arguments: Arg1: fffff900c4c31000, memory referenced. Arg2: 0000000000000001, value 0 = read operation, 1 = write operation. Arg3: fffff96000156a34, If non-zero, the instruction address which referenced the bad memory address. Arg4: 0000000000000000, (reserved) [...] FAULTING_IP: win32k!memmove+64 fffff960`00156a34 488901 mov qword ptr [rcx],rax MM_INTERNAL_CODE: 0 DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT BUGCHECK_STR: 0x50 CURRENT_IRQL: 0 TRAP_FRAME: fffff880074a0210 -- (.trap 0xfffff880074a0210) .trap 0xfffff880074a0210 NOTE: The trap frame does not contain all registers. Some register values may be zeroed or incorrect. rax=fffff47cffffe440 rbx=0000000000000000 rcx=fffff900c4c31000 rdx=000000000141f518 rsi=0000000000000000 rdi=0000000000000000 rip=fffff96000156a34 rsp=fffff880074a03a8 rbp=0000000000000010 r8=0000000000000018 r9=0000000000000001 r10=fffff900c4c211a8 r11=fffff900c4c30ff0 r12=0000000000000000 r13=0000000000000000 r14=0000000000000000 r15=0000000000000000 iopl=0 nv up ei pl nz na pe nc win32k!memmove+0x64: fffff960`00156a34 488901 mov qword ptr [rcx],rax ds:a020:fffff900`c4c31000=???????????????? .trap Resetting default scope LAST_CONTROL_TRANSFER: from fffff800028fa017 to fffff8000287d5c0 STACK_TEXT: fffff880`074a00a8 fffff800`028fa017 : 00000000`00000050 fffff900`c4c31000 00000000`00000001 fffff880`074a0210 : nt!KeBugCheckEx fffff880`074a00b0 fffff800`0287b6ee : 00000000`00000001 fffff900`c4c31000 fffff880`074a0400 fffff900`c4c30fd8 : nt! ?? ::FNODOBFM::`string'+0x4174f fffff880`074a0210 fffff960`00156a34 : fffff960`00252e40 fffff900`c4c30f98 00000000`00000003 fffff900`c48f2eb0 : nt!KiPageFault+0x16e fffff880`074a03a8 fffff960`00252e40 : fffff900`c4c30f98 00000000`00000003 fffff900`c48f2eb0 fffff960`002525dc : win32k!memmove+0x64 fffff880`074a03b0 fffff960`0031d38e : 00000000`000028a6 fffff900`c4c30fd8 00000000`00000000 fffff900`c4c21008 : win32k!EPATHOBJ::bClone+0x138 fffff880`074a0400 fffff960`000f07bb : fffff880`00002640 fffff900`c576aca0 00000000`00002640 fffff880`00000641 : win32k!RFONTOBJ::bInsertMetricsPlusPath+0x17e fffff880`074a0540 fffff960`000eccf7 : fffff880`074a2640 fffff880`074a0a68 fffff880`074a0b40 fffff800`00000641 : win32k!xInsertMetricsPlusRFONTOBJ+0xe3 fffff880`074a0610 fffff960`000ec998 : fffff880`074a0b40 fffff880`074a0a68 fffff900`c0480014 00000000`00000179 : win32k!RFONTOBJ::bGetGlyphMetricsPlus+0x1f7 fffff880`074a0690 fffff960`000ec390 : fffff980`00000000 fffff880`074a0830 fffff900`c04a8000 fffff800`00000008 : win32k!ESTROBJ::vCharPos_H3+0x168 fffff880`074a0710 fffff960`000ed841 : 00000000`41800000 00000000`00000000 00000000`0000000a fffff880`074a0830 : win32k!ESTROBJ::vInit+0x350 fffff880`074a07a0 fffff960`000ed4ef : fffff880`074a0ca0 fffff900`c576aca0 ffffd08c`00000020 ffffffff`ffffffff : win32k!GreGetTextExtentExW+0x275 fffff880`074a0a60 fffff800`0287c853 : 00000000`00000000 fffff880`074a0ca0 00000000`00000001 fffff880`00000000 : win32k!NtGdiGetTextExtentExW+0x237 fffff880`074a0bb0 00000000`750a213a : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13 00000000`0025e1c8 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x750a213a --- We have also observed a number of other system bugchecks caused by the particular TTF file with various stack traces indicating a pool corruption condition. For example, on Windows 7 32-bit a crash occurs only while deleting the font, under the following call stack: --- 9823bc7c 90d8dec1 fb634cf0 fb60ecf0 00000001 win32k!RFONTOBJ::vDeleteCache+0x56 9823bca8 90d14209 00000000 00000000 00000001 win32k!RFONTOBJ::vDeleteRFONT+0x190 9823bcd0 90d15e00 9823bcf4 fb62ccf0 00000000 win32k!PUBLIC_PFTOBJ::bLoadFonts+0x6fb 9823bd00 90ddf48e 00000008 fbc16ff8 912f8fc8 win32k!PFTOBJ::bUnloadWorkhorse+0x114 9823bd28 8267ea06 13000117 0040fa24 775e71b4 win32k!GreRemoveFontMemResourceEx+0x60 9823bd28 775e71b4 13000117 0040fa24 775e71b4 nt!KiSystemServicePostCall --- While we have not determined the specific root cause of the vulnerability, we have pinpointed the offending mutations to reside in the "OS/2" table. The issue reproduces on Windows 7 (32 and 64-bit). It is easiest to reproduce with Special Pools enabled for win32k.sys (leading to an immediate crash when the bug is triggered), but it it also possible to observe a system crash on a default Windows installation as a consequence of pool corruption and resulting system instability. In order to reproduce the problem with the provided sample, it might be necessary to use a custom program which displays all of the font's glyphs at various point sizes. Attached is an archive with the proof-of-concept mutated TTF file, together with the original font used to generate it and a corresponding kernel crash log from Windows 7 64-bit. Proof of Concept: https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/38714.zip