Re: [Wireshark-dev] Npcap 0.03 call for test
Hi Jim, Pascal, This IRQL_NOT_LESS_OR_EQUAL (a) BSoD seems to be caused by NdisAcquireSpinLock call in function NPF_StartUsingOpenInstance has referred to freed Open struct memory, I have tried to fix it in latest installer, you may try it at: https://svn.nmap.org/nmap-exp/yang/NPcap-LWF/npcap-nmap-0.03-r6.exe Cheers, Yang On Fri, Aug 7, 2015 at 9:51 AM, Jim Young wrote: > Hello Yang, > > > After installing 0.03-r5 on my Windows 8.1 system I too am see a BSOD when > starting Wireshark, tshark or dumpcap. > > Like Pascal's Bugcheck Analysis my crashes are also reporting bug check > string: IRQL_NOT_LESS_OR_EQUAL (a) > > 2: kd> .symfix C:\Symbols > > 2: kd> .reload > > Loading Kernel Symbols > > ... > > > > ... > > Loading User Symbols > > . > > Loading unloaded module list > > > > 2: kd> !analyze -v > > > *** > > * > * > > *Bugcheck Analysis > * > > * > * > > > *** > > > IRQL_NOT_LESS_OR_EQUAL (a) > > 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 a kernel debugger is available get the stack backtrace. > > Arguments: > > Arg1: a620, memory referenced > > Arg2: 0002, IRQL > > Arg3: 0001, bitfield : > > bit 0 : value 0 = read operation, 1 = write operation > > bit 3 : value 0 = not an execute operation, 1 = execute operation (only on > chips which support this level of status) > > Arg4: f802a914e0cc, address which referenced memory > > > Debugging Details: > > -- > > > *** ERROR: Module load completed but symbols could not be loaded for > npf.sys > > *** ERROR: Symbol file could not be found. Defaulted to export symbols > for packet.dll - > > > WRITE_ADDRESS: unable to get nt!MmNonPagedPoolStart > > unable to get nt!MmSizeOfNonPagedPoolInBytes > > a620 > > > CURRENT_IRQL: 2 > > > FAULTING_IP: > > nt!KeAcquireSpinLockRaiseToDpc+1c > > f802`a914e0cc f0480fba2900lock bts qword ptr [rcx],0 > > > DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT > > > BUGCHECK_STR: AV > > > PROCESS_NAME: dumpcap.exe > > > ANALYSIS_VERSION: 6.3.9600.17336 (debuggers(dbg).150226-1500) amd64fre > > > TRAP_FRAME: d0009e22a600 -- (.trap 0xd0009e22a600) > > NOTE: The trap frame does not contain all registers. > > Some register values may be zeroed or incorrect. > > rax=0002 rbx= rcx=a620 > > rdx=e00024ae9a70 rsi= rdi= > > rip=f802a914e0cc rsp=d0009e22a790 rbp=d0009e22ab80 > > r8=e00022bf3610 r9=000e r10=0801 > > r11=e00025387040 r12= r13= > > r14= r15= > > iopl=0 nv up ei pl zr na po nc > > nt!KeAcquireSpinLockRaiseToDpc+0x1c: > > f802`a914e0cc f0480fba2900lock bts qword ptr [rcx],0 > ds:`a620= > > Resetting default scope > > > LAST_CONTROL_TRANSFER: from f802a91d27e9 to f802a91c6ca0 > > > STACK_TEXT: > > d000`9e22a4b8 f802`a91d27e9 : `000a `a620 > `0002 `0001 : nt!KeBugCheckEx > > d000`9e22a4c0 f802`a91d103a : `0001 ` > ` d000`9e22a730 : nt!KiBugCheckDispatch+0x69 > > d000`9e22a600 f802`a914e0cc : `0001 c001` > c001`6f840a01 ` : nt!KiPageFault+0x23a > > d000`9e22a790 f801`c221b19a : ` e000`2529b080 > `0001 d000`9e22ab80 : nt!KeAcquireSpinLockRaiseToDpc+0x1c > > d000`9e22a7c0 f801`c221ba38 : `1ef0 e000`24ae9a00 > ` d000` : npf+0x319a > > d000`9e22a7f0 f802`a949b77f : `0001 e000`24ae9a70 > e000`24ae9a70 `0001 : npf+0x3a38 > > d000`9e22a880 f802`a949ad22 : d000`9e22aa38 ` > ` ` : nt!IopXxxControlFile+0xa4f > > d000`9e22aa20 f802`a91d24b3 : e000`25299080 d000`001f0003 > 0004`a71ecc08 0004` : nt!NtDeviceIoControlFile+0x56 > > d000`9e22aa90 7fff`16ff123a : 7fff`14375fe3 7f71`9a924c5b > `0003 ` : nt!KiSystemServiceCopyEnd+0x13 > > 0004`a71ecbb8 7fff`14375fe3 : 7f71`9a924c5b `0003 > ` `0013 : ntdll!NtDeviceIoControlFile+0xa > > 0004`a71ecbc0 7fff`16b01bb0 : `1ef0 7fff`16f9713a > 000
[Wireshark-dev] Crash during fuzzing
Hi list II was fuzzing a protocol, and I experienced a crash. The fuzz-test.sh gave me this output $ ../tools/fuzz-test.sh -b run ../data/hpfeed_all_packets_sample.pcap [...] Starting pass 130: ../data/hpfeeds_all_packets_sample.pcap: (-nVxr) (-nr) OK Starting pass 131: ../data/hpfeeds_all_packets_sample.pcap: (-nVxr) (-nr) OK Starting pass 132: ../data/hpfeeds_all_packets_sample.pcap: (-nVxr) (-nr) OK Starting pass 133: ../data/hpfeeds_all_packets_sample.pcap: (-nVxr) ../tools/fuzz-test.sh: line 189: 8725 Segmentation fault (core dumped) "$RUNNER" $COMMON_ARGS $ARGS $TMP_DIR/$TMP_FILE > /dev/null 2>> $TMP_DIR/$ERR_FILE ERROR Processing failed. Capture info follows: Input file: ../data/hpfeed_all_packets_sample.pcap Output file: /tmp/fuzz-2015-08-10-7120.pcap stderr follows: Input file: ../data/hpfeed_all_packets_sample.pcap Build host information: Linux hardcore 3.13.0-61-generic #100-Ubuntu SMP Wed Jul 29 11:21:34 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux Distributor ID: Ubuntu Description: Ubuntu 14.04.3 LTS Release: 14.04 Codename: trusty Return value: 139 Dissector bug: 0 Valgrind error count: 0 Command and args: run/tshark -nVxr ** ERROR:../epan/wmem/wmem_allocator_strict.c:77:wmem_strict_block_check_canaries: assertion failed: (canary[i] == WMEM_CANARY_VALUE) So I tried to reproduce the error, but when I issued run/tshark -nVxr /tmp/fuzz-2015-08-10-7120.pcap no crash happened. Is this the right way to reproduce a bug the fuzzer found? If yes, why it is not crashing? Thanks for your suggestions. Dario. ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Crash during fuzzing
The best way to reproduce fuzzer bugs is with ./tools/test-captures.sh which sets all the same environment variables and flags as the main fuzz script. Since the error was in a memory canary, valgrind and/or ASAN may also prove useful. Evan On Mon, Aug 10, 2015 at 3:52 PM, Dario Lombardo wrote: > Hi list > II was fuzzing a protocol, and I experienced a crash. The fuzz-test.sh gave > me this output > > $ ../tools/fuzz-test.sh -b run ../data/hpfeed_all_packets_sample.pcap > [...] > Starting pass 130: > ../data/hpfeeds_all_packets_sample.pcap: (-nVxr) (-nr) OK > Starting pass 131: > ../data/hpfeeds_all_packets_sample.pcap: (-nVxr) (-nr) OK > Starting pass 132: > ../data/hpfeeds_all_packets_sample.pcap: (-nVxr) (-nr) OK > Starting pass 133: > ../data/hpfeeds_all_packets_sample.pcap: (-nVxr) ../tools/fuzz-test.sh: > line 189: 8725 Segmentation fault (core dumped) "$RUNNER" $COMMON_ARGS > $ARGS $TMP_DIR/$TMP_FILE > /dev/null 2>> $TMP_DIR/$ERR_FILE > > ERROR > Processing failed. Capture info follows: > > Input file: ../data/hpfeed_all_packets_sample.pcap > Output file: /tmp/fuzz-2015-08-10-7120.pcap > > stderr follows: > > Input file: ../data/hpfeed_all_packets_sample.pcap > > Build host information: > Linux hardcore 3.13.0-61-generic #100-Ubuntu SMP Wed Jul 29 11:21:34 UTC > 2015 x86_64 x86_64 x86_64 GNU/Linux > Distributor ID: Ubuntu > Description: Ubuntu 14.04.3 LTS > Release: 14.04 > Codename: trusty > > Return value: 139 > > Dissector bug: 0 > > Valgrind error count: 0 > > > > > Command and args: run/tshark -nVxr > > ** > ERROR:../epan/wmem/wmem_allocator_strict.c:77:wmem_strict_block_check_canaries: > assertion failed: (canary[i] == WMEM_CANARY_VALUE) > > So I tried to reproduce the error, but when I issued > > run/tshark -nVxr /tmp/fuzz-2015-08-10-7120.pcap > > no crash happened. Is this the right way to reproduce a bug the fuzzer > found? If yes, why it is not crashing? > Thanks for your suggestions. > Dario. > > ___ > Sent via:Wireshark-dev mailing list > Archives:https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Crash during fuzzing
No crash still happening... $ ../tools/test-captures.sh -b run ../data/hpfeeds_all_packets_sample.pcap Testing file ../data/hpfeeds_all_packets_sample.pcap... - with tree... OK - without tree... OK - without tree but with a read filter... OK $ On Mon, Aug 10, 2015 at 10:09 PM, Evan Huus wrote: > The best way to reproduce fuzzer bugs is with ./tools/test-captures.sh > which sets all the same environment variables and flags as the main > fuzz script. > > Since the error was in a memory canary, valgrind and/or ASAN may also > prove useful. > > Evan > > On Mon, Aug 10, 2015 at 3:52 PM, Dario Lombardo > wrote: > > Hi list > > II was fuzzing a protocol, and I experienced a crash. The fuzz-test.sh > gave > > me this output > > > > $ ../tools/fuzz-test.sh -b run ../data/hpfeed_all_packets_sample.pcap > > [...] > > Starting pass 130: > > ../data/hpfeeds_all_packets_sample.pcap: (-nVxr) (-nr) OK > > Starting pass 131: > > ../data/hpfeeds_all_packets_sample.pcap: (-nVxr) (-nr) OK > > Starting pass 132: > > ../data/hpfeeds_all_packets_sample.pcap: (-nVxr) (-nr) OK > > Starting pass 133: > > ../data/hpfeeds_all_packets_sample.pcap: (-nVxr) > ../tools/fuzz-test.sh: > > line 189: 8725 Segmentation fault (core dumped) "$RUNNER" > $COMMON_ARGS > > $ARGS $TMP_DIR/$TMP_FILE > /dev/null 2>> $TMP_DIR/$ERR_FILE > > > > ERROR > > Processing failed. Capture info follows: > > > > Input file: ../data/hpfeed_all_packets_sample.pcap > > Output file: /tmp/fuzz-2015-08-10-7120.pcap > > > > stderr follows: > > > > Input file: ../data/hpfeed_all_packets_sample.pcap > > > > Build host information: > > Linux hardcore 3.13.0-61-generic #100-Ubuntu SMP Wed Jul 29 11:21:34 UTC > > 2015 x86_64 x86_64 x86_64 GNU/Linux > > Distributor ID: Ubuntu > > Description: Ubuntu 14.04.3 LTS > > Release: 14.04 > > Codename: trusty > > > > Return value: 139 > > > > Dissector bug: 0 > > > > Valgrind error count: 0 > > > > > > > > > > Command and args: run/tshark -nVxr > > > > ** > > > ERROR:../epan/wmem/wmem_allocator_strict.c:77:wmem_strict_block_check_canaries: > > assertion failed: (canary[i] == WMEM_CANARY_VALUE) > > > > So I tried to reproduce the error, but when I issued > > > > run/tshark -nVxr /tmp/fuzz-2015-08-10-7120.pcap > > > > no crash happened. Is this the right way to reproduce a bug the fuzzer > > found? If yes, why it is not crashing? > > Thanks for your suggestions. > > Dario. > > > > > ___ > > Sent via:Wireshark-dev mailing list > > Archives:https://www.wireshark.org/lists/wireshark-dev > > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev > > mailto:wireshark-dev-requ...@wireshark.org > ?subject=unsubscribe > ___ > Sent via:Wireshark-dev mailing list > Archives:https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-requ...@wireshark.org > ?subject=unsubscribe > ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Crash during fuzzing
Hi Dario, Le 10 août 2015 10:27 PM, "Dario Lombardo" a écrit : > > No crash still happening... > > $ ../tools/test-captures.sh -b run ../data/hpfeeds_all_packets_sample.pcap > Testing file ../data/hpfeeds_all_packets_sample.pcap... > - with tree... OK > - without tree... OK > - without tree but with a read filter... OK > $ You need to run it on the fuzzed capture (/tmp/fuzz-2015-08-10-7120.pcap), not on the original one. Pascal. > On Mon, Aug 10, 2015 at 10:09 PM, Evan Huus wrote: >> >> The best way to reproduce fuzzer bugs is with ./tools/test-captures.sh >> which sets all the same environment variables and flags as the main >> fuzz script. >> >> Since the error was in a memory canary, valgrind and/or ASAN may also >> prove useful. >> >> Evan >> >> On Mon, Aug 10, 2015 at 3:52 PM, Dario Lombardo >> wrote: >> > Hi list >> > II was fuzzing a protocol, and I experienced a crash. The fuzz-test.sh gave >> > me this output >> > >> > $ ../tools/fuzz-test.sh -b run ../data/hpfeed_all_packets_sample.pcap >> > [...] >> > Starting pass 130: >> > ../data/hpfeeds_all_packets_sample.pcap: (-nVxr) (-nr) OK >> > Starting pass 131: >> > ../data/hpfeeds_all_packets_sample.pcap: (-nVxr) (-nr) OK >> > Starting pass 132: >> > ../data/hpfeeds_all_packets_sample.pcap: (-nVxr) (-nr) OK >> > Starting pass 133: >> > ../data/hpfeeds_all_packets_sample.pcap: (-nVxr) ../tools/fuzz-test.sh: >> > line 189: 8725 Segmentation fault (core dumped) "$RUNNER" $COMMON_ARGS >> > $ARGS $TMP_DIR/$TMP_FILE > /dev/null 2>> $TMP_DIR/$ERR_FILE >> > >> > ERROR >> > Processing failed. Capture info follows: >> > >> > Input file: ../data/hpfeed_all_packets_sample.pcap >> > Output file: /tmp/fuzz-2015-08-10-7120.pcap >> > >> > stderr follows: >> > >> > Input file: ../data/hpfeed_all_packets_sample.pcap >> > >> > Build host information: >> > Linux hardcore 3.13.0-61-generic #100-Ubuntu SMP Wed Jul 29 11:21:34 UTC >> > 2015 x86_64 x86_64 x86_64 GNU/Linux >> > Distributor ID: Ubuntu >> > Description: Ubuntu 14.04.3 LTS >> > Release: 14.04 >> > Codename: trusty >> > >> > Return value: 139 >> > >> > Dissector bug: 0 >> > >> > Valgrind error count: 0 >> > >> > >> > >> > >> > Command and args: run/tshark -nVxr >> > >> > ** >> > ERROR:../epan/wmem/wmem_allocator_strict.c:77:wmem_strict_block_check_canaries: >> > assertion failed: (canary[i] == WMEM_CANARY_VALUE) >> > >> > So I tried to reproduce the error, but when I issued >> > >> > run/tshark -nVxr /tmp/fuzz-2015-08-10-7120.pcap >> > >> > no crash happened. Is this the right way to reproduce a bug the fuzzer >> > found? If yes, why it is not crashing? >> > Thanks for your suggestions. >> > Dario. >> > >> > ___ >> > Sent via:Wireshark-dev mailing list >> > Archives:https://www.wireshark.org/lists/wireshark-dev >> > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev >> > mailto:wireshark-dev-requ...@wireshark.org ?subject=unsubscribe >> ___ >> Sent via:Wireshark-dev mailing list >> Archives:https://www.wireshark.org/lists/wireshark-dev >> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev >> mailto:wireshark-dev-requ...@wireshark.org ?subject=unsubscribe > > > > ___ > Sent via:Wireshark-dev mailing list > Archives:https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-requ...@wireshark.org ?subject=unsubscribe ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Crash during fuzzing
On Mon, Aug 10, 2015 at 10:39 PM, Pascal Quantin wrote: > Hi Dario, > > Le 10 août 2015 10:27 PM, "Dario Lombardo" > a écrit : > > > > No crash still happening... > > > > $ ../tools/test-captures.sh -b run > ../data/hpfeeds_all_packets_sample.pcap > > Testing file ../data/hpfeeds_all_packets_sample.pcap... > > - with tree... OK > > - without tree... OK > > - without tree but with a read filter... OK > > $ > > You need to run it on the fuzzed capture (/tmp/fuzz-2015-08-10-7120.pcap), > not on the original one. > > Pascal. > > > Of course, I got it just after I sent my email. Actually the crash happens. Thank you. ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Npcap 0.03 call for test
Hello Yang, I installed npcap-nmap-0.03-r6.exe but am still getting the IRQL_NOT_LESS_OR_EQUAL (a) BSoD on my Windows 8.1. system immediately when I start Wireshark. I went back retested 0.03-r3, 0.03-r4 and 0.03-r5 to confirm that its only r5 and r6 that trigger the immediate BSoD on my system. Here's the last BSoD WinDbg output when using Npcap 0.03-r6. - 2: kd> .symfix C:\Symbols 2: kd> .reload Loading Kernel Symbols ... Loading User Symbols . Loading unloaded module list 2: kd> !analyze -v *** * * *Bugcheck Analysis* * * *** IRQL_NOT_LESS_OR_EQUAL (a) 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 a kernel debugger is available get the stack backtrace. Arguments: Arg1: a620, memory referenced Arg2: 0002, IRQL Arg3: 0001, bitfield : bit 0 : value 0 = read operation, 1 = write operation bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status) Arg4: f8013ff660cc, address which referenced memory Debugging Details: -- *** ERROR: Module load completed but symbols could not be loaded for npf.sys *** ERROR: Symbol file could not be found. Defaulted to export symbols for packet.dll - WRITE_ADDRESS: unable to get nt!MmNonPagedPoolStart unable to get nt!MmSizeOfNonPagedPoolInBytes a620 CURRENT_IRQL: 2 FAULTING_IP: nt!KeAcquireSpinLockRaiseToDpc+1c f801`3ff660cc f0480fba2900lock bts qword ptr [rcx],0 DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT BUGCHECK_STR: AV PROCESS_NAME: dumpcap.exe ANALYSIS_VERSION: 6.3.9600.17336 (debuggers(dbg).150226-1500) amd64fre TRAP_FRAME: d00035417600 -- (.trap 0xd00035417600) NOTE: The trap frame does not contain all registers. Some register values may be zeroed or incorrect. rax=0002 rbx= rcx=a620 rdx=e001230a2900 rsi= rdi= rip=f8013ff660cc rsp=d00035417790 rbp=d00035417b80 r8=e0011fed41a0 r9=000e r10=0801 r11=e00122517440 r12= r13= r14= r15= iopl=0 nv up ei pl zr na po nc nt!KeAcquireSpinLockRaiseToDpc+0x1c: f801`3ff660cc f0480fba2900lock bts qword ptr [rcx],0 ds:`a620= Resetting default scope LAST_CONTROL_TRANSFER: from f8013ffea7e9 to f8013ffdeca0 STACK_TEXT: d000`354174b8 f801`3ffea7e9 : `000a `a620 `0002 `0001 : nt!KeBugCheckEx d000`354174c0 f801`3ffe903a : `0001 ` ` d000`35417730 : nt!KiBugCheckDispatch+0x69 d000`35417600 f801`3ff660cc : `0001 c002` c002`018bf601 ` : nt!KiPageFault+0x23a d000`35417790 f801`688d7186 : ` e001`230474c0 `0001 d000`35417b80 : nt!KeAcquireSpinLockRaiseToDpc+0x1c d000`354177c0 f801`688d7a24 : `1ef0 e001`230a2900 ` d000` : npf+0x3186 d000`354177f0 f801`402b377f : `0001 e001`230a2900 e001`230a2900 `0001 : npf+0x3a24 d000`35417880 f801`402b2d22 : d000`35417a38 ` ` ` : nt!IopXxxControlFile+0xa4f d000`35417a20 f801`3ffea4b3 : e001`21d2c080 d000`001f0003 0017`cb91ca98 0017` : nt!NtDeviceIoControlFile+0x56 d000`35417a90 7ffe`449c123a : 7ffe`41b65fe3 da4a`605d0f0d `0003 ` : nt!KiSystemServiceCopyEnd+0x13 0017`cb91ca48 7ffe`41b65fe3 : da4a`605d0f0d `0003 ` `0013 : ntdll!NtDeviceIoControlFile+0xa 0017`cb91ca50 7ffe`42151bb0 : `1ef0 7ffe`4496713a `0020 ` : KERNELBASE!DeviceIoControl+0x121 0017`cb91cac0 7ffe`399f3d65 : 0017`cba14960 0017`cb91cdb0 ` 0017`cb91cdb0 : KERNEL32!DeviceIoControlImplementation+0x80 0017`cb91cb10 0017`cba14960 : 0017`cb91cdb0 ` 0017`cb91cdb0
