We have discovered that the win32k!UMPDOBJ::LockSurface function discloses portions of uninitialized pool memory to user-mode clients. The bug was encountered on Windows 7 64-bit; other versions were not tested.

The leak was detected in the context of the splwow64.exe process, under the following stack trace:

Where 00 denote bytes which are properly initialized, while ff indicate uninitialized values. We have a strong suspicion that the region corresponds to a SURFOBJ structure, and the 4 uninitialized bytes at offsets 0x2c-0x2f are a compiler-introduced padding between the cjBits and pvBits fields, to align the pvBits field to a 8-byte boundary. This would also explain why the bug only manifests itself on 64-bit builds of Windows.

The disclosed bytes originate from a pool allocation made in win32k!AllocateObject, and specifically from a surface object descriptor. The buffer is copied to a user-mode mapping created with the win32k!EngAllocUserMemEx function, whose address is then returned by the win32k!NtGdiEngLockSurface system call.

As the splwow64.exe process runs with the privileges of the local user, we believe no special rights in the system are required to access the disclosed kernel memory. A proof-of-concept program is not provided for this issue, but it has been observed at normal system runtime.

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.