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

[Hostile Defunct]

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 buffer
access 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 generate
any more interrupts before finishing a DMA transfer.
 
// Gadi Elishayov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.winpcap.org/pipermail/winpcap-bugs/attachments/20090522/6311d179/attachment.htm