[Winpcap-bugs] A potential bug in the NPF Driver Code

[Gianluca Varenni]

  ----- Original Message ----- 
  From: Hostile Defunct 
  To: winpcap-bugs at winpcap.org 
  Sent: Friday, May 22, 2009 11:48 AM
  Subject: [Winpcap-bugs] A potential bug in the NPF Driver Code


  NPF_tap is called for every incoming packet and runs at DISPATCH_LEVEL.
  The NPF buffering scheme contains a different buffer for each Adapter/CPU combination.

Each buffer contains a spinlock member called `BufferLock`.That spinlock is acquired at DISPATCH_LEVEL in the NPF_tap in order to synchronize the bufferaccess with the NPF_TransferDataComplete that can potentially run on a different CPU. The following scenario seems a bit problematic: Hardware: 1 CPU, 1 NIC.a)  NPF_tap is called with a partial packet and BufferLock is called.
The spinlock is acquired, and we call NdisTransferData.
NdisTransferData returns NDIS_STATUS_PENDING, and a NIC performs a DMA transfer
asynchronously.

b)  During the transfer, NPF_tap is called again, this time with a different packet.
We try to acquire the spinlock and cause a deadlock since we've already acquired
it before on the same CPU, and no-one will ever have a chance to release it. This wouldn't be a problem if it was written somewhere that a single NIC can't generateany more interrupts before finishing a DMA transfer. // Gadi ElishayovIt's something that could happen. I acutally never understood if it's possible that a ProtocolReceive handler (i.e. NPF_tap) can be called again *before* the ProtocolTransferData has been called. Havingsaid that, jus the fact that a spinlock might be held while returning from a protocol handler is a mistake. The right approach would be to defer the copy of the packet to the ProtocolTransferDataComplete,using a temporary buffer for the NdisTransferData. The bottom line of it is that I've never seen any network card returning a partial packet so that it was necessary to call NdisTransferData *and* transferDatawas returning STATUS_PENDING.I will definitely work on a patch to it, but I won't have a way to test it....Thanks for the bug report!GV 

------------------------------------------------------------------------------


  _______________________________________________
  Winpcap-bugs mailing list
  Winpcap-bugs at winpcap.org
  https://www.winpcap.org/mailman/listinfo/winpcap-bugs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.winpcap.org/pipermail/winpcap-bugs/attachments/20090522/b39f3c1d/attachment.htm