[Winpcap-users] ANNOUNCE: WinPcap 4.0 alpha1 has been released
gianluca.varenni at cacetech.com
Fri May 12 15:59:56 GMT 2006
----- Original Message -----
From: "Bryan Kadzban" <bryan at kadzban.is-a-geek.net>
To: <winpcap-users at winpcap.org>
Sent: Thursday, May 11, 2006 4:40 PM
Subject: Re: [Winpcap-users] ANNOUNCE: WinPcap 4.0 alpha1 has been released
>> This new release of WinPcap has been thoroughly tested internally.
>> However, due to the extensive modifications to the kernel driver
>> code, we feel that a testing period from the WinPcap community is
>> necessary to guarantee a level of stability comparable with WinPcap
>> 3.1. We encourage everyone to play with this new version and report
>> any problems on the various WinPcap mailing lists.
>I haven't actually tried the driver yet, but I think I see a "leak" of
>some sort in the BIOCSETOID / BIOCQUERYOID ioctl handlers.
>Right after the TRACE_MESSAGE call, the code calls
>NPF_StartUsingBinding. Any error path after this calls
>NPF_StopUsingBinding, except one -- if the buffer is too small, the code
>calls the SET_FAILURE_BUFFER_SMALL() macro, then breaks out of the case,
>but it doesn't NPF_StopUsingBinding that I can see. I'm not sure it
>matters, either, but it *might* end up deadlocking when npf gets
>unloaded. (This is packetNtx/driver/Packet.c, near line 1524.)
You are right, it's a bug in the driver. Fortunately enough, this bug is not
exploitable using the normal Packet or pcap APIs, since you need to forge a
specific IOCTL request to the driver in order to that buggy error path. In
any case I'll fix the problem during the weekend :-))
Thank you very much for the bug report!
Have a nice day
>I will try to get the precompiled driver running tomorrow on a test
>machine or two, though, to see if it fixes the crash I was seeing. I
>think it will, based on the code, but it's never bad to actually try it.
>> Winpcap-users mailing list
>> Winpcap-users at winpcap.org
More information about the Winpcap-users