CVE-2016-7259: An empty file into the blue

A binary analysis of CVE-2016-7259: A win32k kernel bug.


The vulnerability was found by one of our fuzzers in 2015 (made by Richard) and analyzed later by me (Sebastien).

The vulnerability deals with *.pfm and *.pfb files (strangely enough, not their format per se):

  • Printer Font Metric (PFM) is a binary version of AFM (Adobe Font Metrics). It contains font metric information.
  • Printer Font Binary (PFB) is a binary PostScript font format created by Adobe Systems. It contains a font's glyph data.

Vulnerability Description

A crash in the Windows windowing kernel graphic component (win32k.sys) happens when a specially crafted PostScript Type 1 font (*.pfm) font file is loaded.

The crash is due to Windows OS not properly checking that the size of the related *.pfb file size is 0.

Simply put: having an empty *.pfb file crashes the system.

Stack Trace

(See version_information section for software version information)

Information and stack trace at time of crash with public Microsoft symbols:

*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *

Use !analyze -v to get detailed debugging information.

BugCheck 1E, {c0000005, 8e3c7280, 0, 18}

*** WARNING: Unable to verify checksum for Test.exe
*** ERROR: Module load completed but symbols could not be loaded for Test.exe
Probably caused by : win32k.sys ( win32k!PUBLIC_PFTOBJ::bLoadFonts+ffffffffffffff33 )

Followup:     MachineOwner

8216a9f4 cc              int     3
1: kd> !analyze -v
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *

This is a very common bugcheck.  Usually the exception address pinpoints
the driver/function that caused the problem.  Always note this address
as well as the link date of the driver/image that contains this address.
Arg1: c0000005, The exception code that was not handled
Arg2: 8e3c7280, The address that the exception occurred at
Arg3: 00000000, Parameter 0 of the exception
Arg4: 00000018, Parameter 1 of the exception

Debugging Details:

BUGCHECK_P1: ffffffffc0000005

BUGCHECK_P2: ffffffff8e3c7280



READ_ADDRESS:  00000018

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%p referenced memory at 0x%p. The memory could not be %s.

8e3c7280 f6411808        test    byte ptr [ecx+18h],8


BUGCHECK_STR:  0x1E_c0000005_R


CPU_MHZ: db6

CPU_VENDOR:  GenuineIntel





PROCESS_NAME:  ConsoleApplica


ANALYSIS_VERSION: 10.0.10240.9 x86fre

EXCEPTION_RECORD:  a8815898 -- (.exr 0xffffffffa8815898)
ExceptionAddress: 8e3c7280 (win32k!PUBLIC_PFTOBJ::bLoadFonts+0xffffff33)
   ExceptionCode: c0000005 (Access violation)
  ExceptionFlags: 00000000
NumberParameters: 2
   Parameter[0]: 00000000
   Parameter[1]: 00000018
Attempt to read from address 00000018

TRAP_FRAME:  a8815974 -- (.trap 0xffffffffa8815974)
ErrCode = 00000000
eax=00000000 ebx=00000000 ecx=00000000 edx=00c295b0 esi=9ee20398 edi=00000002
eip=8e3c7280 esp=a88159e8 ebp=a8815a4c iopl=0         nv up ei pl nz na po nc
cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000             efl=00010202
8e3c7280 f6411808        test    byte ptr [ecx+18h],8       ds:0023:00000018=??
Resetting default scope

LAST_CONTROL_TRANSFER:  from 821e6aeb to 8216a9f4

a8814ee4 821e6aeb 00000003 6296f150 00000065 nt!RtlpBreakWithStatusInstruction
a8814f38 821e6605 8303f340 a8815338 a881536c nt!KiBugCheckDebugBreak+0x1f
a881530c 821695c6 0000001e c0000005 8e3c7280 nt!KeBugCheck2+0x676
a8815330 821694fd 0000001e c0000005 8e3c7280 nt!KiBugCheck2+0xc6
a8815350 821e479b 0000001e c0000005 8e3c7280 nt!KeBugCheckEx+0x19
a881536c 8217f672 a8815898 8226f180 a8815460 nt!KiFatalExceptionHandler+0x1a
a8815390 8217f644 a8815898 8226f180 a8815460 nt!ExecuteHandler2+0x26
a8815450 820fa3bd a8815898 a8815460 00010037 nt!ExecuteHandler+0x24
a881587c 8217b156 a8815898 00000000 a8815974 nt!KiDispatchException+0x101
a88158e8 8217d99b 00000000 00000000 00000000 nt!KiDispatchTrapException+0x4e
a88158e8 8e3c7280 00000000 00000000 00000000 nt!KiTrap0E+0x1a7
a8815a4c 8e3c0bb8 8da41000 000000d8 00000002 win32k!PUBLIC_PFTOBJ::bLoadFonts+0xffffff33
a8815aac 8e3c0aee 00000002 00000011 00000000 win32k!GreAddFontResourceWInternal+0xa3
a8815bf4 8217a417 00a65558 000000d8 00000002 win32k!NtGdiAddFontResourceW+0xbc
a8815bf4 77bcca70 00a65558 000000d8 00000002 nt!KiSystemServicePostCall
002ee75c 75e1b67c 75e1adfb 00a65558 000000d8 ntdll!KiFastSystemCallRet
002ee760 75e1adfb 00a65558 000000d8 00000002 GDI32!NtGdiAddFontResourceW+0xa
002ee7a0 75e4993b 002ee7d4 00000011 00000000 GDI32!GdiAddFontResourceW+0x5b
002ee9f8 01024b8b 00415b70 00000010 00000000 GDI32!AddFontResourceExA+0xeb
WARNING: Stack unwind information not available. Following frames may be wrong.
002ef4d0 01029314 002b02d4 0000003f 00322540 Test+0x84b8b
002ef7d0 0107763a 00000003 00322518 00322820 Test+0x89314
002ef81c 0107781d 002ef838 76074198 7fd66000 Test+0xd763a
002ef824 76074198 7fd66000 76074170 fa31b76d Test+0xd781d
002ef838 77bb2cb1 7fd66000 fa4bb319 00000000 KERNEL32!BaseThreadInitThunk+0x24
002ef880 77bb2c7f ffffffff 77bde751 00000000 ntdll!__RtlUserThreadStart+0x2b
002ef890 00000000 0100b103 7fd66000 00000000 ntdll!_RtlUserThreadStart+0x1b


8e3c7280 f6411808        test    byte ptr [ecx+18h],8


SYMBOL_NAME:  win32k!PUBLIC_PFTOBJ::bLoadFonts+ffffffffffffff33

FOLLOWUP_NAME:  MachineOwner


IMAGE_NAME:  win32k.sys


IMAGE_VERSION:  6.3.9600.18405

BUCKET_ID_FUNC_OFFSET:  ffffffffffffff33

FAILURE_BUCKET_ID:  0x1E_c0000005_R_win32k!PUBLIC_PFTOBJ::bLoadFonts

BUCKET_ID:  0x1E_c0000005_R_win32k!PUBLIC_PFTOBJ::bLoadFonts

PRIMARY_PROBLEM_CLASS:  0x1E_c0000005_R_win32k!PUBLIC_PFTOBJ::bLoadFonts


FAILURE_ID_HASH_STRING:  km:0x1e_c0000005_r_win32k!public_pftobj::bloadfonts

FAILURE_ID_HASH:  {de897383-506f-34a6-612f-9272467400a7}

Followup:     MachineOwner


The faulty syscall is win32k!NtGdiAddFontResourceW. According to Reactos source code the function prototype is:

    _In_reads_(cwc) WCHAR *pwszFiles,
    _In_ ULONG cwc,
    _In_ ULONG cFiles,
    _In_ FLONG f,
    _In_ DWORD dwPidTid,
    _In_opt_ DESIGNVECTOR *pdv);

The crash happens on a NULL pointer dereference in the win32k!PUBLIC_PFTOBJ::bLoadFonts function:

1: kd> .trap 0xffffffffa8815974
ErrCode = 00000000
eax=00000000 ebx=00000000 ecx=00000000 edx=00c295b0 esi=9ee20398 edi=00000002
eip=8e3c7280 esp=a88159e8 ebp=a8815a4c iopl=0         nv up ei pl nz na po nc
cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000             efl=00010202
8e3c7280 f6411808        test    byte ptr [ecx+18h],8       ds:0023:00000018=??

The previous line is:

; in win32k!PUBLIC_PFTOBJ::bLoadFonts
.text:001A827D mov     ecx, [esi+eax*4] ; ecx = nullptr

Register configuration is as follows:

  • ESI register points to a kernel pool memory block.

  • EAX register is the number file passed to the syscall (win32k!NtGdiAddFontResourceW) in the 1st argument.
    • Note: multiple file names can be passed to the syscall with the | separator character.
  • EDI is the number of files passed in the 1st argument of the syscall.

The kernel pool memory block (where the null pointer lies) is allocated and has a size of 0x90 bytes:

1: kd> !pool @esi
Pool page 9ee20398 region is Paged session pool
 9ee20000 size:  338 previous size:    0  (Allocated)  Gfnt
 9ee20338 size:   10 previous size:  338  (Free)       Free
 9ee20348 size:   48 previous size:   10  (Allocated)  Ussm
*9ee20390 size:   90 previous size:   48  (Allocated) *Gffv
        Pooltag Gffv : Gdi FONTFILEVIEW
 9ee20420 size:   68 previous size:   90  (Allocated)  Usqm
 9ee20488 size:  288 previous size:   68  (Allocated)  Gla5
 9ee20710 size:  8f0 previous size:  288  (Allocated)  Gla1

The kernel pool memory block is allocated in the same function (win32k!PUBLIC_PFTOBJ::bLoadFonts):

; in win32k!PUBLIC_PFTOBJ::bLoadFonts
.text:001A8449  mov     ecx, edi ; ecx = edi = number of files = 2
; [...]
.text:001A844F  mov     edx, 'vffG'      ; block tag
.text:001A8454  lea     eax, ds:7[edi*4] ; lea eax,[edi*4+7] ; edi = 2 ; eax = 0x0f
.text:001A845B  shl     ecx, 6           ; before: ecx = 2; after: ecx = 0x80
.text:001A845E  and     eax, 0FFFFFFF8h  ; eax = 8
.text:001A8461  push    1
.text:001A8463  add     ecx, eax         ; NumberOfBytes: 0x80 + 8 = 0x88
.text:001A8465  mov     [esp+64h+var_28], eax
.text:001A8469  call    PALLOCMEM2(x,x,x)
.text:001A846E  mov     [esp+60h+pFontFileView], eax ; kernel pool block pointer

Then the win32k!vLoadFontFileView function is called:

; in win32k!PUBLIC_PFTOBJ::bLoadFonts
.text:001A8539  push    [esp+80h+pFontFileView] ; unsigned __int16 *
.text:001A853D  call    vLoadFontFileView

Inside win32k!vLoadFontFileView, both of the font files (*.pfm and *.pfb) are loaded and then mapped. The mapping occurs in the win32k!MapFontFiles function.

; in win32k!vLoadFontFileView
.text:0018D5BD  push    [ebp+arg_C]     ; 1: kd> dp 9efb2a90
.text:0018D5BD                          ; 9efb2a90  00000000 00000000 00000000 00000000
.text:0018D5C0  mov     edx, [ebp+arg_0] ; 1: kd> dd 8d9f1108
.text:0018D5C0                           ; 8d9f1108  8d9f1110 8d9f1150 00000000 00000000
.text:0018D5C3  mov     ecx, ebx        ; ebx = ecx = 2 (number of files)
.text:0018D5C5  push    [ebp+arg_8]     ; points on P
.text:0018D5C8  call    MapFontFiles(ulong,_FONTFILEVIEW * *,void * *,ulong *)

The call stack on win32k!MapFontFiles function entry looks like this:

3: kd> k
# ChildEBP RetAddr
00 8a4e7988 8e1805cd win32k!MapFontFiles
01 8a4e79bc 8e19b542 win32k!vLoadFontFileView+0x18a
02 8a4e7a4c 8e194bb8 win32k!PUBLIC_PFTOBJ::bLoadFonts+0x1f5
03 8a4e7aac 8e194aee win32k!GreAddFontResourceWInternal+0xa3
04 8a4e7bf4 81574417 win32k!NtGdiAddFontResourceW+0xbc

Inside win32k!MapFontFiles we have a loop that maps both of the font files using the win32k!EngMapFontFileFDInternal function:

; in win32k!MapFontFiles
.text:001A1CAA  add     eax, ecx        ; 2nd -> eax = 9efb2a9c
.text:001A1CAC  mov     edx, ecx
.text:001A1CAE  push    0
.text:001A1CB0  push    eax
.text:001A1CB1  mov     eax, [ebp+var_4]
.text:001A1CB4  mov     ecx, [ecx+eax]
.text:001A1CB7  call    EngMapFontFileFDInternal(x,x,x,x)
.text:001A1CBC  test    eax, eax        ;  eax = 0 on 2nd pass
.text:001A1CBE  jz      @@ErrorMapFontFile
.text:001A1CC4  mov     ecx, [ebp+arg_0] ; 1: kd> dp 9efb2a90
.text:001A1CC4                          ; 9efb2a90  00b70000 00000000 000002f3 00000000
.text:001A1CC4                          ; 9efb2aa0  46140003 38616c47 010807fe 00000001
.text:001A1CC4                          ; 9efb2ab0  80000000 00000000 00008208 00000000
.text:001A1CC7  inc     edi
.text:001A1CC8  mov     eax, [ebp+var_C] ; 8
.text:001A1CCB  add     ecx, 4
.text:001A1CCE  mov     [ebp+arg_0], ecx
.text:001A1CD1  cmp     edi, [ebp+number_of_files] ; 2
.text:001A1CD4  jb      short loc_1A1CAA ; 2nd -> eax = 9efb2a9c

The first loop pass is used to open and map the *.pfm font file, the second one being used for the *.pfb file.

In w32k!EngMapFontFileFDInternal we have a call to win32k!bCreateSection:

; in w32k!EngMapFontFileFDInternal
.text:00142AB9  mov     ecx, [ebx+28h]  ; du poi(@ebx + 28)
.text:00142AB9                          ; 8da41000  "\??\C:\WORK\FONTS\TEST\FONTS\LIB"
.text:00142AB9                          ; 8da41040  "TEST63.PFB"
.text:00142AB9                          ;
.text:00142ABC  shr     eax, 3
.text:00142ABF  and     al, 1
.text:00142AC1  movzx   eax, al
.text:00142AC4  push    eax             ; int (0)
.text:00142AC5  lea     eax, [esp+74h+var_5C]
.text:00142AC9  push    eax             ; struct _FILEVIEW *
.text:00142ACA  push    esi             ; unsigned __int16 * (0)
.text:00142ACB  call    bCreateSection(ushort *,_FILEVIEW *,int,int *,uchar)

Inside win32k!bCreateSection, the code uses nt!IoCreateFile. Here (after the call to open the file), the resulting handle refers to the *.pfb file:

!handle 80000bf8

PROCESS 9dcd2040  SessionId: 1  Cid: 0af0    Peb: 7f58c000  ParentCid: 0e58
    DirBase: 00e08540  ObjectTable: af8583c0  HandleCount: <Data Not Accessible>
    Image: FontLoader.exe

Kernel handle Error reading handle count.

80000bf8: Object: ab226d70  GrantedAccess: 001200a9 Entry: a47827f0

Object: ab226d70  Type: (8023c868) File
    ObjectHeader: ab226d58 (new version)

        HandleCount: 1  PointerCount: 1

        Directory Object: 00000000  Name: \Work\fonts\test\fonts\Test-Italic63.pfb {HarddiskVolume2}

The code then uses nt!ZwQueryInformationFile to query file information. Note that the code doesn't check if the file size is 0.

;  in win32!bCreateSection
.text:000DC47B  lea     eax, [ebp+FileInformation]
.text:000DC47E  push    5               ; FileInformationClass
.text:000DC480  push    18h             ; Length
.text:000DC482  push    eax             ; FileInformation
.text:000DC483  lea     eax, [ebp+IoStatusBlock]
.text:000DC486  push    eax             ; IoStatusBlock
.text:000DC487  push    [ebp+FileHandle] ; FileHandle
.text:000DC48A  call    edi ; ZwQueryInformationFile(x,x,x,x,x)

The code then calls win32k!ZwWin32CreateSection which is merely a wrapper around nt!ZwCreateSection:

;  in win32k!bCreateSection
.text:000DC548  mov     [ebp+ObjectAttributes.Length], 18h
.text:000DC552  mov     [ebp+ObjectAttributes.RootDirectory], ebx
.text:000DC558  mov     [ebp+ObjectAttributes.Attributes], 200h
.text:000DC562  mov     [ebp+ObjectAttributes.ObjectName], ebx
.text:000DC568  mov     [ebp+ObjectAttributes.SecurityDescriptor], ebx
.text:000DC56E  mov     [ebp+ObjectAttributes.SecurityQualityOfService], ebx
.text:000DC574  test    cl, 2
.text:000DC577  jnz     loc_21098C
.text:000DC57D  push    ecx             ; int
.text:000DC57E  push    ecx             ; int
.text:000DC57F  push    [ebp+FileHandle] ; FileHandle
.text:000DC582  neg     esi
.text:000DC584  lea     eax, [ebp+MaximumSize]
.text:000DC587  push    ecx             ; int
.text:000DC588  sbb     esi, esi
.text:000DC58A  lea     ecx, [ebp+var_60] ; int
.text:000DC58D  and     esi, 0FFFFFFE4h
.text:000DC590  add     esi, 20h
.text:000DC593  push    esi             ; SectionPageProtection
.text:000DC594  push    eax             ; MaximumSize
.text:000DC595  lea     eax, [ebp+ObjectAttributes]
.text:000DC59B  push    eax             ; ObjectAttributes
.text:000DC59C  call    ZwWin32CreateSection(x,x,x,x,x,x,x,x,x) ; fail inside!!!
.text:000DC5A1  test    eax, eax        ; HRESULT indicates error
.text:000DC5A3  js      loc_21091E      ; take jcc

The code can't create a section of an empty file, which results in an error code.

The file handle is then closed and an error is signaled by zeroing the eax register:

;  in win32k!bCreateSection
.text:0021091E  push    [ebp+FileHandle] ; Handle
.text:00210921  call    ds:ZwClose(x)
.text:00210927 loc_210927:
.text:00210927  xor     eax, eax  ; function returns 0
.text:00210929  jmp     loc_DC613 ; go to function epilogue

The 0 return value is still seen as an error by the caller (win32k!EngMapFontFileFDInternal) which also exits:

; in win32k!EngMapFontFileFDInternal
.text:00142ACB  call    bCreateSection(ushort *,_FILEVIEW *,int,int *,uchar)
.text:00142AD0  mov     [esp+70h+ret_val], eax
; [...]
.text:00142AE4  mov     eax, [esp+70h+ret_val]
.text:00142AE8 loc_142AE8:
.text:00142AE8  test    eax, eax
.text:00142AEA  jz      loc_142B77  ; to function epilogue

Back to win32k!MapFontFiles on the call site to win32k!EngMapFontFileFDInternal. We can see that a 0 return value is also taken as an error.

The file is then unmapped and the first pointer sized value in the font file view (pointer by the esi register) is also zeroed. This value corresponds to the file mapping.

; in win32k!MapFontFiles
.text:001A1CB7  call    EngMapFontFileFDInternal(x,x,x,x)
.text:001A1CBC  test    eax, eax        ;  eax = 0 on 2nd pass
.text:001A1CBE  jz      @@ErrorMapFontFile
; [...]
.text:00230C89 @@ErrorMapFontFile:
.text:00230C89  test    edi, edi
.text:00230C8B  jz      short loc_230CAC
.text:00230C8D  sub     ebx, esi
.text:00230C8F  sub     [ebp+arg_4], esi
.text:00230C92 loc_230C92:
.text:00230C92  push    dword ptr [esi]
.text:00230C94  call    EngUnmapFontFileFD(x)  ; unmap file
.text:00230C99  mov     eax, [ebp+arg_4]
.text:00230C9C  xor     ecx, ecx
.text:00230C9E  mov     [esi], ecx      ; esi=pFontFileView ; ecx = 0
.text:00230CAC loc_230CAC:
.text:00230CAC  xor     al, al  ; exits with 0

The function then exits (with a zero value, indicating an error) and we are back to win32k!vLoadFontFileView.

Inside this function the return code is checked and the win32k!vLoadFontFileView function also exits but the error code is not backported to the caller (PUBLIC_PFTOBJ::bLoadFonts).

; in  win32k!PUBLIC_PFTOBJ::bLoadFonts
.text:001A853D  call    vLoadFontFileView
.text:001A8542  mov     eax, [esp+60h+p_minus_pfontfileview] ; eax = [a5861a34]=00000000
.text:001A8542      ; --------------------------
.text:001A8542      ; fonte file view first DWORD has been zeroed!
.text:001A8542      ; 3: kd> dp 9e417dd8 L1
.text:001A8542      ; 9e417dd8  00000000
; [...]
.text:001A8570 loc_1A8570:
.text:001A8570  cmp     [esp+60h+var_ghsemPublicPFT], 0 ; [a5861a18]=00000000
.text:001A8575  jz      loc_1A86FF  ; clean up

The file is unmapped once again but the pointer is 0:

; in  win32k!PUBLIC_PFTOBJ::bLoadFonts
.text:001A8710  push    dword ptr [ebx+esi*4] ; 0 !!!
.text:001A8713  call    EngUnmapFontFileFD(x)

And then the font file view is used again, but as the pointer is 0 the code tries to dereference the NULL address:

; in  win32k!PUBLIC_PFTOBJ::bLoadFonts
.text:001A8279  mov     esi, [esp+60h+pFontFileView]
.text:001A8279          ; note: first dword is 0
.text:001A8279          ; 1: kd> dp 9e417dd8 L4
.text:001A8279          ; 9e417dd8  00000000 9e417e20 1471fe00 01d13591
.text:001A827D loc_1A827D:
.text:001A827D  mov     ecx, [esi+eax*4] ; ecx is a NULL pointer
.text:001A8280  test    byte ptr [ecx+18h], 8 ; crash here!!!

Version Information

Windows version - Windows 8.1 Update 1 x86 [up to date on 2016-08-25]:

3: kd> vertarget
Windows 8.1 Kernel Version 9600 MP (4 procs) Free x86 compatible
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 9600.18379.x86fre.winblue_ltsb.160614-0600
Machine Name:
Kernel base = 0x8160b000 PsLoadedModuleList = 0x81805618
Debug session time: Thu Aug 25 16:03:28.779 2016 (UTC + 2:00)
System Uptime: 0 days 0:12:29.534

Win32k.sys module information:

3: kd> lm vm win32k
Browse full module list
start    end        module name
8e234000 8e59b000   win32k     (pdb symbols)          g:\symbols\win32k.pdb\ACF8092B8851410DBBB1D0C026BFCCAE2\win32k.pdb
    Loaded symbol image file: win32k.sys
    Image path: \SystemRoot\System32\win32k.sys
    Image name: win32k.sys
    Browse all global symbols  functions  data
    Timestamp:        Fri Jul 08 16:17:54 2016 (577FB612)
    CheckSum:         003599F0
    ImageSize:        00367000
    File version:     6.3.9600.18405
    Product version:  6.3.9600.18405
    File flags:       0 (Mask 3F)
    File OS:          40004 NT Win32
    File type:        3.7 Driver
    File date:        00000000.00000000
    Translations:     0409.04b0
    CompanyName:      Microsoft Corporation
    ProductName:      Microsoft Windows Operating System
    InternalName:     win32k.sys
    OriginalFilename: win32k.sys
    ProductVersion:   6.3.9600.18405
    FileVersion:      6.3.9600.18405 (winblue_ltsb.160708-0600)
    FileDescription:  Multi-User Win32 Driver
    LegalCopyright:   Microsoft Corporation. All rights reserved.


The file format of the font itself is not in cause.

You should check for any PostScript Type 1 font (*.pfm extension) font file and its associated *.pfb file.

If the *.pfb file is empty (file size is 0 byte), then the crash can occur.


NULL pointer dereference protection on newer Windows systems will mitigate this problem as it is not possible to allocate the page at 0.

Time Line

  • 2015-12-xx: [QB] Vulnerability found; Pushed for later thorough analysis
  • 2016-08-25: [QB] Vulnerability unstacked and analyzed
  • 2016-08-26: [QB] Report vulnerability to Microsoft
  • 2016-08-26: [MS] Microsoft acknowledge reception
  • 2016-09-15: [MS] Microsoft has a successful repro
  • 2016-11-02: [QB] Ask if they deemed the bug as being important or not
  • 2016-11-10: [MS] Acknowledge fix will be released in Dec. patch Tuesday
  • 2016-12-13: [MS] Fix for CVE-2016-7259 is released
  • 2016-12-14: [QB] Quick look at the patch and blog release