none
inject data on FWPM_LAYER_OUTBOUND_TRANSPORT_V4 layer got a BSOD RRS feed

  • Question

  • Hi,all

    I use the WFP inject data on FWPM_LAYER_OUTBOUND_TRANSPORT_V4 layer, but sometimes i get a BSOD. please help

    It looks like some memory is invalid???

    STACK_TEXT: 
    fffff880`02dc9f18 fffff800`ffc95369 : 00000000`0000000a 00000000`0000000a 00000000`00000002 00000000`00000000 : nt!KeBugCheckEx
    fffff880`02dc9f20 fffff800`ffc93be0 : 00000000`00000000 fffffa80`09c8e640 00000000`b25d3400 fffff880`02dca060 : nt!KiBugCheckDispatch+0x69
    fffff880`02dca060 fffff880`01b2f5de : fffffa80`062d8830 fffff880`01b613ab 00000000`00000000 fffffa80`09e78010 : nt!KiPageFault+0x260
    fffff880`02dca1f0 fffff880`01b30465 : fffff880`01c62b90 00000000`00000000 fffff880`02dc0000 00000000`00000000 : tcpip!IppPreparePacketChecksum+0x29e
    fffff880`02dca2a0 fffff880`01b5eccb : fffffa80`06b16e18 fffffa80`06b16b38 fffff880`02dca5a0 fffffa80`06b16a58 : tcpip!IppPacketizeDatagrams+0x135
    fffff880`02dca3b0 fffff880`01bca635 : 00000000`00000007 fffff880`01c62b90 fffffa80`09e78010 00000000`00000000 : tcpip!IppSendDatagramsCommon+0x6eb
    fffff880`02dca570 fffff880`01d1aad8 : fffffa80`059eca10 00000000`00000007 fffff880`02dc5000 fffffa80`09e78010 : tcpip!IppInspectInjectTlSend+0x185
    fffff880`02dca6a0 fffff800`ffcd7415 : 00000000`00000002 fffffa80`06f8e170 11dff477`8e44982a 900181d1`e778ce85 : fwpkclnt!FwpsInjectionHandleDestroy0+0x908
    fffff880`02dca730 fffff800`ffcd8225 : fffff880`01d1aa50 fffff880`02dca930 00000000`00000010 00000000`00000246 : nt!KeExpandKernelStackAndCalloutInternal+0xe5
    fffff880`02dca830 fffff880`01d1b9fe : 00000000`00000000 fffff880`02dca970 fffffa80`09c8e4e0 00000000`00000000 : nt!KeExpandKernelStackAndCalloutEx+0x25
    fffff880`02dca870 fffff880`01d1bb07 : fffffa80`00000000 fffffa80`06f8e170 00000000`00000000 00000000`00000000 : fwpkclnt!FwpsInjectNetworkReceiveAsync0+0x88a
    fffff880`02dcaa70 fffff880`038d290c : fffffa80`09c8e640 fffffa80`09f6fa58 fffffa80`08581850 fffffa80`086700d0 : fwpkclnt!FwpsInjectTransportSendAsync0+0x63
    fffff880`02dcaae0 fffff880`038d2a6c : 00000000`00000000 fffffa80`086700d0 00000000`00000080 fffff8a0`6b707000 : MyNetmon+0x990c
    fffff880`02dcabb0 fffff800`ffc3e3d5 : fffffa80`06f72b00 00000000`00000000 fffff8a0`00000000 00000000`029967d8 :  MyNetmon+0x9a6c
    fffff880`02dcac10 fffff800`ffc7c116 : fffff880`009c7180 fffffa80`06f72b00 fffff880`009d2e40 fffffa80`05533040 : nt!PspSystemThreadStartup+0x59
    fffff880`02dcac60 00000000`00000000 : fffff880`02dcb000 fffff880`02dc5000 00000000`00000000 00000000`00000000 : nt!KiStartSystemThread+0x16

    Thursday, March 14, 2013 10:07 AM

Answers

  • I have a few question about your code:

    1) why are you invalidating the ports in thhe UDP HEader.  If you need to drop the packet, then you just return FWP_ACTION_BLOCK, and set the ABSORB flag (make sure you clean up the clone without injecting it).

    2) why are you treating every NET_BUFFER as a UDP_HEADER?  @ OUTBOUND_TRANSPORT, you are indicated 1 NBL that will be packetized.  This NBL's offset is @ the transport header, so the first NB should have the UDP Header.  All other NBs (assuming there are more) will contain the payload.

    3) How are you guaranteeing that packet->controlData remains valid for the duration of the processing of the packet?  If you do this, you should deep copy the controlData.

    Thanks,


    Dusty Harper [MSFT]
    Microsoft Corporation
    ------------------------------------------------------------
    This posting is provided "AS IS", with NO warranties and confers NO rights
    ------------------------------------------------------------

    • Marked as answer by bianlu Friday, March 22, 2013 7:59 AM
    Tuesday, March 19, 2013 6:14 PM
    Moderator

All replies

  • this driver  is reference to the wdk example "inspect"


    • Edited by bianlu Thursday, March 14, 2013 10:19 AM
    Thursday, March 14, 2013 10:13 AM
  • I see someone have same problem,and an answer of MSFT is

    "  As a workaround you can modify the sample such that packet is cloned from within classifyFn instead of referenced and clone outside of classifyFn.

       The sample's the approach (calling FwpsReferenceNetBufferList0 from classifyFn and then cloning it from the worker thread) makes it susceptible to the subtle changes introduced in Win7  "

    I have modified my code ,and there is a new crash, please help

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

    DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
    An attempt was made to access a pageable (or completely invalid) address at an
    interrupt request level (IRQL) that is too high.  This is usually
    caused by drivers using improper addresses.
    If kernel debugger is available get stack backtrace.
    Arguments:
    Arg1: fffff9801802cfea, memory referenced
    Arg2: 0000000000000002, IRQL
    Arg3: 0000000000000000, value 0 = read operation, 1 = write operation
    Arg4: fffff88001b349c9, address which referenced memory

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


    READ_ADDRESS:  fffff9801802cfea Special pool

    CURRENT_IRQL:  2

    FAULTING_IP:
    tcpip!UdpDeliverDatagrams+1e9
    fffff880`01b349c9 66394802        cmp     word ptr [rax+2],cx

    DEFAULT_BUCKET_ID:  WIN8_DRIVER_FAULT

    BUGCHECK_STR:  AV

    PROCESS_NAME:  System

    TRAP_FRAME:  fffff88002f473d0 -- (.trap 0xfffff88002f473d0)
    NOTE: The trap frame does not contain all registers.
    Some register values may be zeroed or incorrect.
    rax=fffff9801802cfe8 rbx=0000000000000000 rcx=0000000000004605
    rdx=fffff98018186fe8 rsi=0000000000000000 rdi=0000000000000000
    rip=fffff88001b349c9 rsp=fffff88002f47560 rbp=fffff88002f47660
     r8=0000000000000000  r9=0000000000000000 r10=fffffa8007780840
    r11=fffffa8007780440 r12=0000000000000000 r13=0000000000000000
    r14=0000000000000000 r15=0000000000000000
    iopl=0         nv up ei ng nz na po nc
    tcpip!UdpDeliverDatagrams+0x1e9:
    fffff880`01b349c9 66394802        cmp     word ptr [rax+2],cx ds:fffff980`1802cfea=????
    Resetting default scope

    LAST_CONTROL_TRANSFER:  from fffff802718f5369 to fffff802718f6040

    STACK_TEXT: 
    fffff880`02f47288 fffff802`718f5369 : 00000000`0000000a fffff980`1802cfea 00000000`00000002 00000000`00000000 : nt!KeBugCheckEx
    fffff880`02f47290 fffff802`718f3be0 : 00000000`00000000 fffffa80`06ec56f0 fffff980`1802cf00 fffff880`02f473d0 : nt!KiBugCheckDispatch+0x69
    fffff880`02f473d0 fffff880`01b349c9 : fffff880`02f47660 fffffa80`057e53c0 00000000`00000000 00000000`00000000 : nt!KiPageFault+0x260
    fffff880`02f47560 fffff880`01b34fa0 : fffff880`00000001 fffffa80`00000000 fffffa80`00000000 fffff980`1802cfe8 : tcpip!UdpDeliverDatagrams+0x1e9
    fffff880`02f476f0 fffff880`01b34411 : fffffa80`057e53c0 fffff802`71aeb701 ffffffff`ffdf0002 00000000`00000005 : tcpip!UdpReceiveDatagrams+0x270
    fffff880`02f47840 fffff880`01b337c8 : fffff880`02f47a08 fffffa80`06c07a78 00000000`00000000 00000000`00000000 : tcpip!IppDeliverListToProtocol+0xe1
    fffff880`02f478f0 fffff880`01b39201 : fffff880`01c4eb90 fffff880`01c4eb90 fffffa80`059008f0 fffff880`02f47a08 : tcpip!IppProcessDeliverList+0x68
    fffff880`02f479a0 fffff880`01b06ea7 : fffffa80`0742ab00 fffffa80`00000000 fffff802`718ff700 fffff880`02f47ba8 : tcpip!IppReceiveHeaderBatch+0x211
    fffff880`02f47ad0 fffff880`01b06957 : fffff880`02f47cb0 fffffa80`03ad8040 00000000`00000000 00000002`ced03659 : tcpip!IppLoopbackIndicatePackets+0x393
    fffff880`02f47ba0 fffff802`718e1743 : fffff880`01b06760 fffff980`0137cfb0 00000000`00000000 00000000`00010296 : tcpip!IppLoopbackTransmit+0x1f7
    fffff880`02f47c10 fffff802`7192e951 : fffff802`71aff110 fffffa80`03ad8040 fffff802`718e16e4 fffff802`718ff700 : nt!IopProcessWorkItem+0x5f
    fffff880`02f47c80 fffff802`7189e3d5 : 00000000`00000000 00000000`00000080 fffff802`7192e810 fffffa80`03ad8040 : nt!ExpWorkerThread+0x142
    fffff880`02f47d10 fffff802`718dc116 : fffff880`009c0180 fffffa80`03ad8040 fffffa80`03ab9040 fffffa80`03adb940 : nt!PspSystemThreadStartup+0x59
    fffff880`02f47d60 00000000`00000000 : fffff880`02f48000 fffff880`02f42000 00000000`00000000 00000000`00000000 : nt!KiStartSystemThread+0x16


    STACK_COMMAND:  kb

    FOLLOWUP_IP:
    tcpip!UdpDeliverDatagrams+1e9
    fffff880`01b349c9 66394802        cmp     word ptr [rax+2],cx

    SYMBOL_STACK_INDEX:  3

    SYMBOL_NAME:  tcpip!UdpDeliverDatagrams+1e9

    FOLLOWUP_NAME:  MachineOwner

    MODULE_NAME: tcpip

    IMAGE_NAME:  tcpip.sys

    DEBUG_FLR_IMAGE_TIMESTAMP:  50fe2daf

    BUCKET_ID_FUNC_OFFSET:  1e9

    FAILURE_BUCKET_ID:  AV_VRF_tcpip!UdpDeliverDatagrams

    BUCKET_ID:  AV_VRF_tcpip!UdpDeliverDatagrams

    Followup: MachineOwner

    Thursday, March 14, 2013 10:37 AM
  • 1) What OS are you running?

    2) Can you proivde me with a link to download a memory dump [ DHarper @AT@ Microsoft .DOT. Com ]  ?

    3) You mention the inspect sample...  What modifications did you make to the sample (if any) ?

    Thanks


    Dusty Harper [MSFT]
    Microsoft Corporation
    ------------------------------------------------------------
    This posting is provided "AS IS", with NO warranties and confers NO rights
    ------------------------------------------------------------

    Thursday, March 14, 2013 6:18 PM
    Moderator
  • hi,dusty

    1,win8 build 9200

    2,the dump file size is 400mb,how i sent to you

    3,i modify the the transport Header of packet

    Friday, March 15, 2013 2:51 AM
  • You will need to give me a link to a file share site like Microsoft SkyDrive, RapidShare, or some FTP site.

    Can you send me snippets of the modifications you made to the sample?

    Thanks,


    Dusty Harper [MSFT]
    Microsoft Corporation
    ------------------------------------------------------------
    This posting is provided "AS IS", with NO warranties and confers NO rights
    ------------------------------------------------------------

    Friday, March 15, 2013 4:49 AM
    Moderator
  • thanks you dusty

    these is some codes

    I found that if i modify loopback packet, it will crash

    nb=NET_BUFFER_LIST_FIRST_NB(clonedNetBufferList);
     while (nb)
     {
      UDP_HEADER *pUdpHead=NULL;
      UCHAR tempHead[40]={0};
      IP_HEADER *pIpHead=NULL;
      pIpHead=(IP_HEADER*)&(tempHead[0]);

      pUdpHead=NdisGetDataBuffer(
       nb,
       sizeof(UDP_HEADER),
       NULL,
       sizeof(UINT16),
       0
       );
      if (pUdpHead)
      {
      
       if (IsNeedDropPacket)
       {
        pUdpHead->uh_dport=0; //make it invalid
        pUdpHead->uh_sport=0;
       }
       else
       {
         //do something else
       }
      }

      nb=NET_BUFFER_NEXT_NB(nb);
     }

     sendArgs.remoteAddress=(UINT8*)(&packet->remoteAddr);
     sendArgs.remoteScopeId=packet->remoteScopeId;
     sendArgs.controlData=packet->controlData;
     sendArgs.controlDataLength=packet->controlDataLength;

     status=FwpsInjectTransportSendAsync0(
      g_InjectionHandle,
      NULL,
      packet->endpointHandle,
      0,
      &sendArgs,
      packet->addressFamily,
      packet->compartmentId,
      clonedNetBufferList,
      Inspect_InjectComplete,
      packet
      );
     if (!NT_SUCCESS(status))
     {
      goto Exit;
     }

    Friday, March 15, 2013 5:31 AM
  • I have received the file, and will take a look this week.

    Thanks.


    Dusty Harper [MSFT]
    Microsoft Corporation
    ------------------------------------------------------------
    This posting is provided "AS IS", with NO warranties and confers NO rights
    ------------------------------------------------------------

    Tuesday, March 19, 2013 4:26 AM
    Moderator
  • I have a few question about your code:

    1) why are you invalidating the ports in thhe UDP HEader.  If you need to drop the packet, then you just return FWP_ACTION_BLOCK, and set the ABSORB flag (make sure you clean up the clone without injecting it).

    2) why are you treating every NET_BUFFER as a UDP_HEADER?  @ OUTBOUND_TRANSPORT, you are indicated 1 NBL that will be packetized.  This NBL's offset is @ the transport header, so the first NB should have the UDP Header.  All other NBs (assuming there are more) will contain the payload.

    3) How are you guaranteeing that packet->controlData remains valid for the duration of the processing of the packet?  If you do this, you should deep copy the controlData.

    Thanks,


    Dusty Harper [MSFT]
    Microsoft Corporation
    ------------------------------------------------------------
    This posting is provided "AS IS", with NO warranties and confers NO rights
    ------------------------------------------------------------

    • Marked as answer by bianlu Friday, March 22, 2013 7:59 AM
    Tuesday, March 19, 2013 6:14 PM
    Moderator
  • thank you very much, Dusty

    1)on OUTBOUND_TRANSPORT layer,1 NBL maybe have more than one NET_BUFFER,every NET_BUFFER is one packet.For example,I sent

    5000 byte, there is one NBL which has 4 NET_BUFFER,they are 1494byte,1494byte,1494byte,and 500byte.I dont want drop all 5000 byte.

    That is wrong?

    2)UDP_HEAD or TCP_HEAD,the beginning of them is port,I modify port,make it invalid to drop one NET_BUFFER

    3)YES,I should deep copy it,I will try it.

    at last,Do you have better way to drop one NET_BUFFER of NBL??


    • Edited by bianlu Wednesday, March 20, 2013 9:34 AM
    Wednesday, March 20, 2013 9:31 AM
  • 1) Yes.  WFP guarantees only 1 packet

    ) To drop the packet, if it is original, set the action to FWP_ACTION_BLOCK (set absorb flag appropriately.  If it is the close, call FwpsFreeCloneNetBufferList.  No need for some mystic magic causing the stack to drop it...

    I suggest looking at the WFPSampler's BASIC_PACKET_INJECTIOn code ...

    http://code.msdn.microsoft.com/Windows-Filtering-Platform-27553baa

    Thanks,


    Dusty Harper [MSFT]
    Microsoft Corporation
    ------------------------------------------------------------
    This posting is provided "AS IS", with NO warranties and confers NO rights
    ------------------------------------------------------------

    Friday, March 22, 2013 7:29 AM
    Moderator
  • Thank you very much harper. Although you didn't know what I mean, but the problem is resolved

    Friday, March 22, 2013 7:59 AM
  • Hi Bianlu

    I've got a very similar BSOD. Could you please provide some details about your issue cause and the fix?

    Just in case the call stack from my dump:

    0: kd> k
    Child-SP          RetAddr           Call Site
    fffff880`1a7fdc28 fffff801`9f289669 nt!KeBugCheckEx
    fffff880`1a7fdc30 fffff801`9f287ee0 nt!KiBugCheckDispatch+0x69
    fffff880`1a7fdd70 fffff880`01ec52e9 nt!KiPageFault+0x260
    fffff880`1a7fdf00 fffff880`01ec58c0 tcpip!UdpDeliverDatagrams+0x1e9
    fffff880`1a7fe090 fffff880`01ec4d31 tcpip!UdpReceiveDatagrams+0x270
    fffff880`1a7fe1e0 fffff880`01ec40e8 tcpip!IppDeliverListToProtocol+0xe1
    fffff880`1a7fe290 fffff880`01ec9b21 tcpip!IppProcessDeliverList+0x68
    fffff880`1a7fe340 fffff880`01ec3304 tcpip!IppReceiveHeaderBatch+0x211
    fffff880`1a7fe470 fffff880`01ece9ac tcpip!IpFlcReceivePackets+0x8d4
    fffff880`1a7fe690 fffff880`01ece289 tcpip!FlpReceiveNonPreValidatedNetBufferListChain+0x29e
    fffff880`1a7fe760 fffff801`9f2cafd5 tcpip!FlReceiveNetBufferListChainCalloutRoutine+0x119
    fffff880`1a7fe860 fffff801`9f2cbde5 nt!KeExpandKernelStackAndCalloutInternal+0xe5
    fffff880`1a7fe960 fffff880`01ece45e nt!KeExpandKernelStackAndCalloutEx+0x25
    fffff880`1a7fe9a0 fffff880`01c6fe2e tcpip!FlReceiveNetBufferListChain+0xae
    fffff880`1a7fea20 fffff880`01cba6e8 ndis!ndisMIndicateNetBufferListsToOpen+0x373
    fffff880`1a7feac0 fffff880`01cbbd0b ndis!ndisDoPeriodicReceivesIndication+0x3a8
    fffff880`1a7feb50 fffff880`01c84bd7 ndis!ndisPeriodicReceivesWorker+0x63
    fffff880`1a7feb80 fffff801`9f231551 ndis!ndisReceiveWorkerThread+0x157
    fffff880`1a7fec10 fffff801`9f26fdd6 nt!PspSystemThreadStartup+0x59
    fffff880`1a7fec60 00000000`00000000 nt!KiStartSystemThread+0x16

    Thursday, May 23, 2013 3:16 PM