The Type1/CFF CharString interpreter code in the Adobe Type Manager Font Driver (ATMFD.DLL) Windows kernel module does not perform nearly any verification that the operand stack is large enough to contain the required instruction operands, which can lead to up to "off-by-three" overreads and overwrites on the interpreter function stack.

Even though the out-of-bounds accesses can take place, a respective "if (op_sp < op_stk)" check at the beginning of the next main loop iterations bails out, making it usually impossible (with one exception) to disclose values from the kernel stack or otherwise exploit most of those conditions. The vulnerable instructions that decrease "op_sp" (the operand stack pointer) below "&op_stk" (a local, 48-entry long array on the kernel stack) are:

1) escape + callothersubr
2) escape + callothersubr + endflex
3) escape + callothersubr + changehints
4) escape + callothersubr + counter{1, 2}
5) escape + add
6) escape + sub 
7) escape + mul
8) escape + div2
9) escape + put
10) escape + get
11) escape + ifelse
12) escape + and
13) escape + or
14) escape + eq
15) escape + roll
16) escape + setcurrentpoint
17) escape + load
18) escape + store

Furthermore, the following opcodes can perform out-of-bounds stack reads without successively bailing out, thus making it possible to leak the value(s) from the kernel stack:

1) escape + dup

The bugs are reproducible with both Type1 and OTF fonts. They are not very serious issues (to our knowledge, only one of the affected operators makes it possible to disclose four bytes from the kernel stack per glyph), but they are illustrative of the overall code quality of the interpreter code found in the Windows kernel. We have checked several builds of the ATMFD.DLL file to see if the three DWORDs immediately below "op_stk" were useful for exploitation (e.g. stored function pointers), but cursory analysis showed that no control-flow related data was stored there in the tested DLLs, which doesn't come as a surprise considering the enormous function stack frame (0x6f4 bytes on Windows 8.1 32-bit).

POC samples are not attached, but it is generally sufficient to invoke any of the above instructions when the operand stack is empty (e.g. at the very beginning of a CharString stream). All Windows editions up to 8.1 are affected (regardless of their bitness).

This bug is subject to a 90 day disclosure deadline. If 90 days elapse without a broadly available patch, then the bug report will automatically become visible to the public.