We have discovered that the win32k!NtGdiEnumFonts system call handler discloses very large portions of uninitialized pool memory to user-mode clients.
The issue can be reproduced by running the attached proof-of-concept program on a system with the Special Pools mechanism enabled for win32k.sys. Then, it is clearly visible that a significant number of the bytes are equal to the markers inserted by Special Pools, and would otherwise contain leftover data that was previously stored in that memory region. In this case, the marker byte is 0x47 ("G"), and a dump of the initial 512 bytes of output is shown below. A full dump of the output can be found in the attached file.
--- cut ---
00000000: e4 01 00 00 70 01 00 00 04 00 00 00 25 00 00 00 ....p.......%...
00000010: 12 00 00 00 00 00 00 00 00 00 00 00 90 01 00 00 ................
00000020: 00 00 00 ee 03 02 01 31 43 00 6f 00 6e 00 73 00 .......1C.o.n.s.
00000030: 6f 00 6c 00 61 00 73 00 00 00 47 47 47 47 47 47 o.l.a.s...GGGGGG
00000040: 47 47 47 47 47 47 47 47 47 47 47 47 47 47 47 47 GGGGGGGGGGGGGGGG
00000050: 47 47 47 47 47 47 47 47 47 47 47 47 47 47 47 47 GGGGGGGGGGGGGGGG
00000060: 47 47 47 47 47 47 00 00 43 00 6f 00 6e 00 73 00 GGGGGG..C.o.n.s.
00000070: 6f 00 6c 00 61 00 73 00 00 00 47 47 47 47 47 47 o.l.a.s...GGGGGG
00000080: 47 47 47 47 47 47 47 47 47 47 47 47 47 47 47 47 GGGGGGGGGGGGGGGG
00000090: 47 47 47 47 47 47 47 47 47 47 47 47 47 47 47 47 GGGGGGGGGGGGGGGG
000000a0: 47 47 47 47 47 47 47 47 47 47 47 47 47 47 47 47 GGGGGGGGGGGGGGGG
000000b0: 47 47 47 47 47 47 47 47 47 47 47 47 47 47 47 47 GGGGGGGGGGGGGGGG
000000c0: 47 47 47 47 47 47 47 47 47 47 47 47 47 47 47 47 GGGGGGGGGGGGGGGG
000000d0: 47 47 47 47 47 47 47 47 47 47 47 47 47 47 47 47 GGGGGGGGGGGGGGGG
000000e0: 47 47 47 47 47 47 00 00 52 00 65 00 67 00 75 00 GGGGGG..R.e.g.u.
000000f0: 6c 00 61 00 72 00 00 00 47 47 47 47 47 47 47 47 l.a.r...GGGGGGGG
00000100: 47 47 47 47 47 47 47 47 47 47 47 47 47 47 47 47 GGGGGGGGGGGGGGGG
00000110: 47 47 47 47 47 47 47 47 47 47 47 47 47 47 47 47 GGGGGGGGGGGGGGGG
00000120: 47 47 47 47 47 47 00 00 43 00 65 00 6e 00 74 00 GGGGGG..C.e.n.t.
00000130: 72 00 61 00 6c 00 20 00 45 00 75 00 72 00 6f 00 r.a.l. .E.u.r.o.
00000140: 70 00 65 00 61 00 6e 00 00 00 47 47 47 47 47 47 p.e.a.n...GGGGGG
00000150: 47 47 47 47 47 47 47 47 47 47 47 47 47 47 47 47 GGGGGGGGGGGGGGGG
00000160: 47 47 47 47 47 47 47 47 64 76 00 08 00 00 00 00 GGGGGGGGdv......
00000170: 47 47 47 47 00 ff 01 02 25 00 00 00 1d 00 00 00 GGGG....%.......
00000180: 08 00 00 00 05 00 00 00 00 00 00 00 11 00 00 00 ................
00000190: 23 00 00 00 90 01 00 00 00 00 00 00 60 00 00 00 #...........`...
000001a0: 60 00 00 00 00 00 ff fe 01 00 02 00 00 00 00 36 `..............6
000001b0: ee 47 47 47 40 00 24 00 00 08 00 00 5e 09 00 00 .GGG@.$.....^...
000001c0: 66 04 00 00 ff 02 00 e1 ff fc 00 40 09 00 00 00 f..........@....
000001d0: 00 00 00 00 9f 01 00 60 00 00 d7 df 61 6c 00 08 .......`....al..
000001e0: 00 00 00 00 e4 01 00 00 70 01 00 00 04 00 00 00 ........p.......
000001f0: 25 00 00 00 12 00 00 00 00 00 00 00 00 00 00 00 %...............
--- cut ---
Repeatedly triggering the vulnerability could allow local authenticated attackers to defeat certain exploit mitigations (kernel ASLR) or read other secrets stored in the kernel address space.
This bug is subject to a 90 day disclosure deadline. After 90 days elapse or a patch has been made broadly available, the bug report will become visible to the public.
