Assertion failure when scanning with Windows IOCP engine (Nmap 7.90, Win10)

[MakofBp]

With Npcap 1.0:

Assertion failed: (*parent_ptr)->index == parent_idx, file src\gh_heap.c, line 98

[dmiller-nmap]

Thanks for this report. This is most likely a bug in the new default Nsock engine, iocp. What Nmap options were you using when it crashed?

As a workaround, you can use --nsock-engine=poll to get the previous default.

[floyd-fuh]

Just a quick "me too". Via Zenmap. My scan was:

nmap -p 1- -T4 -A -v 10.49.1.0/24

It runs fine for quiet a while and then always throws this error at the same place. I encountered it at least twice running the same command. It crashes during the scanning phase (where ports are discovered) and not in the host discovery phase.

[gvanem]

It must have been fixed in the repo since your version was built. I've no problem with:

nmap.exe --nsock-engine=iocp -p 1- -T4 -A -v 10.0.0.0/24

Recompile if you're able to and see the bug disappear.

But, I get this after the report:

dnet: Failed to open device lo0
QUITTING!

[dmiller-nmap]

@gvanem Did you see this crash earlier, or did it not affect you at all? This is probably triggered by specific network circumstances which might not exist on your network. Unfortunately, most Windows users aren't going to be able to recompile on their own.

@floyd-fuh @MakofBp Can you narrow the scope of the scan and generate more debug output for us? Since the crash is in Nsock, it will be limited to service scan (-sV) or NSE (-sC). Please try these scan options and provide a few dozen lines of context prior to the crash: nmap -p 1- -T4 -sV -d9

[floyd-fuh]

Exactly, I used the Zenmap version that was available for download two days ago. I can confirm that --nsock-engine=poll fixed the issue in that version. Unfortunately, I just finished the engagement and had to give back the laptop and don't have access to the network anymore to create further debug output.

[gvanem]

Did you see this crash earlier,

I don't remember. But I do not use option -A that much.

This is probably triggered by specific network circumstances ...

Like what? More likely is the spaghetti-code in gh_heap.c and elsewhere in Nmap.

[me-and]

I've hit the same bug. --nsock-engine=poll works around it for me.

I've put the entire output from the command @dmiller-nmap asked for, specifically from running nmap -sV -6 -p 1- -T4 -d9 fe80::be99:11ff:fe69:4300, in a gist. I've also copied the last couple dozen lines below, but I suspect the problems start earlier, given there are definitely The system detected an invalid pointer address in attempting to use a pointer argument in a call logs before the below.

NSOCK INFO [46.3270s] nsock_connect_tcp(): TCP connection requested to fe80::be99:11ff:fe69:4300:443 (IOD #6) EID 48
NSOCK DEBUG [46.3270s] nsock_pool_add_event(): NSE #48: Adding event (timeout in 5000ms)
NSOCK INFO [46.3270s] nsock_trace_handler_callback(): Callback: CONNECT ERROR [The system detected an invalid pointer address in attempting to use a pointer argument in a call.  (10014)] for EID 48 [fe80::be99:11ff:fe69:4300:443]
Got nsock CONNECT response with status ERROR - aborting this service
NSOCK INFO [46.3270s] nsock_iod_delete(): nsock_iod_delete (IOD #6)
NSOCK DEBUG [46.3270s] event_delete(): event_delete (IOD #6) (EID #48)
NSOCK DEBUG [46.3270s] event_delete(): event_delete (IOD #5) (EID #40)
NSOCK DEBUG [46.3270s] event_delete(): event_delete (IOD #4) (EID #32)
NSOCK DEBUG [46.3270s] event_delete(): event_delete (IOD #3) (EID #24)
NSOCK DEBUG [46.3270s] event_delete(): event_delete (IOD #2) (EID #16)
NSOCK DEBUG [46.3270s] event_delete(): event_delete (IOD #1) (EID #8)
NSOCK DEBUG [46.3270s] nsock_loop(): nsock_loop() started (no timeout). 0 events pending
NSOCK INFO [46.3270s] nsock_iod_new2(): nsock_iod_new (IOD #1)
NSOCK DEBUG [46.3350s] event_new(): event_new (IOD #1) (EID #8)
NSOCK INFO [46.3350s] nsock_connect_tcp(): TCP connection requested to fe80::be99:11ff:fe69:4300:80 (IOD #1) EID 8
NSOCK DEBUG [46.3350s] nsock_pool_add_event(): NSE #8: Adding event (timeout in 1000ms)
NSOCK INFO [46.3350s] nsock_trace_handler_callback(): Callback: CONNECT ERROR [The system detected an invalid pointer address in attempting to use a pointer argument in a call.  (10014)] for EID 8 [fe80::be99:11ff:fe69:4300:80]
NSOCK DEBUG [46.3350s] event_delete(): event_delete (IOD #1) (EID #8)
NSOCK INFO [46.3350s] nsock_iod_delete(): nsock_iod_delete (IOD #1)
NSOCK INFO [46.3350s] nsock_iod_new2(): nsock_iod_new (IOD #2)
NSOCK DEBUG [46.3350s] event_new(): event_new (IOD #2) (EID #17)
NSOCK INFO [46.3350s] nsock_connect_ssl(): SSL connection requested to fe80::be99:11ff:fe69:4300:80/tcp (IOD #2) EID 17
NSOCK DEBUG [46.3350s] nsock_pool_add_event(): NSE #17: Adding event (timeout in 1000ms)
Assertion failed: (*parent_ptr)->index == parent_idx, file src\gh_heap.c, line 98

[dmiller-nmap]

Thanks everyone. We're keeping this under investigation, but we released a bugfix version, Nmap 7.91, which rolls back the change that makes IOCP the default engine on Windows. For Nmap 7.90, the recommended workaround is --nsock-engine=poll, which is the default in 7.80 and 7.91.

[fyodor]

Update: @dmiller-nmap mentioned that he was able to cause an assertion failure today with Nmap 7.95 using --nsock-engine=iocp with an -A scan on his LAN: "Assertion failed: index == heap->count || (*ptr)->index == index, file C:\cygwin64\home\Nmap\nmap-7.95\nsock\src\gh_heap.c, line 71"