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