nmap 7.97 crash: DNS queries to unrelated DNS server

[sausix]

Describe the bug
nmap -sn 192.168.60.0/22 does not yield any results.
But nmap -sn -n 192.168.60.0/22 does.

To Reproduce
Windows. Two network adapters configured. Internet sharing active and working.
Adapter 1: Private network interface on static ip. Without gateway or DNS.
Adapter 2: A regular network interface on DHCP which gets DNS, IP and gateway.
Scan the subnet on the private adapter: nmap -sn 192.168.60.0/22

Expected behavior
Whatever the unrelated DNS server replies about the unknown hosts nmap should not skip all successful ping results.

Version info (please complete the following information):

• OS: Windows 11 Pro 10.0.26100 Build 26100
• Output of nmap --version:

Nmap version 7.97 ( https://nmap.org )
Platform: i686-pc-windows-windows
Compiled with: nmap-liblua-5.4.7 openssl-3.0.16 nmap-libssh2-1.11.1 nmap-libz-1.3.1 nmap-libpcre2-10.45 Npcap-1.82 nmap-libdnet-1.18.0 ipv6
Compiled without:
Available nsock engines: iocp poll select

• Output of nmap --iflist

Starting Nmap 7.97 ( https://nmap.org ) at 2025-06-08 22:22 +0200
************************INTERFACES************************
DEV  (SHORT) IP/MASK                      TYPE     UP   MTU   MAC
unk0 (unk0)  fe80::a5f9:784d:8080:1b42/64 other    down 65535
unk0 (unk0)  169.254.219.162/16           other    down 65535
eth0 (eth0)  fe80::757:b65c:adaf:6c2d/64  ethernet up   1500  8C:32:23:21:F4:9B
eth0 (eth0)  192.168.51.53/24             ethernet up   1500  8C:32:23:21:F4:9B
eth1 (eth1)  fe80::9e64:f02b:e691:37df/64 ethernet up   1500  8C:32:23:21:F4:9C
eth1 (eth1)  192.168.60.1/22              ethernet up   1500  8C:32:23:21:F4:9C
unk1 (unk1)  fe80::7cef:eb89:6d28:f6fd/64 other    down 1500
unk1 (unk1)  169.254.217.210/16           other    down 1500
unk2 (unk2)  fe80::49fc:c076:f361:46c5/64 other    down 1500
unk2 (unk2)  169.254.122.125/16           other    down 1500
unk3 (unk3)  fe80::a5f9:784d:8080:1b42/64 other    down 1500
unk3 (unk3)  169.254.13.96/16             other    down 1500
lo0  (lo0)   ::1/128                      loopback up   -1
lo0  (lo0)   127.0.0.1/8                  loopback up   -1

DEV    WINDEVICE
unk0   \Device\NPF_{09476A2E-A126-427F-973E-23987EE83CDE}
unk0   \Device\NPF_{09476A2E-A126-427F-973E-23987EE83CDE}
eth0   \Device\NPF_{2638A08E-ABAF-4D79-8712-98C0BB2D5000}
eth0   \Device\NPF_{2638A08E-ABAF-4D79-8712-98C0BB2D5000}
eth1   \Device\NPF_{ADEAB8D3-B945-4D4C-8C59-E740C0AF524C}
eth1   \Device\NPF_{ADEAB8D3-B945-4D4C-8C59-E740C0AF524C}
unk1   \Device\NPF_{A9374567-6601-458B-AB1B-8C93667A3798}
unk1   \Device\NPF_{A9374567-6601-458B-AB1B-8C93667A3798}
unk2   \Device\NPF_{61B66488-1E74-441C-B57E-10A0DA541C2F}
unk2   \Device\NPF_{61B66488-1E74-441C-B57E-10A0DA541C2F}
unk3   \Device\NPF_{DA889704-7299-4EE7-AC59-7C9ABBBE4549}
unk3   \Device\NPF_{DA889704-7299-4EE7-AC59-7C9ABBBE4549}
lo0    \Device\NPF_Loopback
lo0    \Device\NPF_Loopback
<none> \Device\NPF_{BA2E3B44-164B-4519-B916-6CAD4DF73947}
<none> \Device\NPF_{D90B47E4-84FC-4AB0-B9B7-1A9C0E613F75}
<none> \Device\NPF_{B27D59F0-7455-4340-B7AA-A01ABCC753D1}

**************************ROUTES**************************
DST/MASK                      DEV  METRIC GATEWAY
255.255.255.255/32            unk0 261
255.255.255.255/32            unk3 281
255.255.255.255/32            unk1 281
255.255.255.255/32            unk2 281
255.255.255.255/32            eth0 281
192.168.51.53/32              eth0 281
192.168.51.255/32             eth0 281
255.255.255.255/32            eth1 281
192.168.60.1/32               eth1 281
192.168.63.255/32             eth1 281
127.255.255.255/32            lo0  331
255.255.255.255/32            lo0  331
127.0.0.1/32                  lo0  331
192.168.51.0/24               eth0 281
192.168.60.0/22               eth1 281
127.0.0.0/8                   lo0  331
224.0.0.0/4                   unk0 261
224.0.0.0/4                   unk1 281
224.0.0.0/4                   unk3 281
224.0.0.0/4                   unk2 281
224.0.0.0/4                   eth0 281
224.0.0.0/4                   eth1 281
224.0.0.0/4                   lo0  331
0.0.0.0/0                     eth0 25     192.168.51.254
fe80::a5f9:784d:8080:1b42/128 unk0 261
fe80::9e64:f02b:e691:37df/128 eth1 281
fe80::a5f9:784d:8080:1b42/128 unk3 281
fe80::757:b65c:adaf:6c2d/128  eth0 281
fe80::7cef:eb89:6d28:f6fd/128 unk1 281
fe80::49fc:c076:f361:46c5/128 unk2 281
::1/128                       lo0  331
fe80::/64                     unk0 261
fe80::/64                     unk1 281
fe80::/64                     unk3 281
fe80::/64                     unk2 281
fe80::/64                     eth1 281
fe80::/64                     eth0 281
ff00::/8                      unk0 261
ff00::/8                      unk1 281
ff00::/8                      eth1 281
ff00::/8                      eth0 281
ff00::/8                      unk2 281
ff00::/8                      unk3 281
ff00::/8                      lo0  331

Additional context
Wireshark shows the ARP responses. nmap does not even show "host down" results.

nmap -sn -vv -d 192.168.60.0/22
Packet.dll present, library version 1.82
wpcap.dll present, library version: Npcap version 1.82, based on libpcap version 1.10.5
Starting Nmap 7.97 ( https://nmap.org ) at 2025-06-08 22:24 +0200
--------------- Timing report ---------------
  hostgroups: min 1, max 100000
  rtt-timeouts: init 1000, min 100, max 10000
  max-scan-delay: TCP 1000, UDP 1000, SCTP 1000
  parallelism: min 0, max 0
  max-retries: 10, host-timeout: 0
  min-rate: 0, max-rate: 0
---------------------------------------------
Initiating ARP Ping Scan at 22:24
Scanning 1023 hosts [1 port/host]
Packet capture filter (device eth1): arp and arp[18:4] = 0x8C322321 and arp[22:2] = 0xF49C
Bogus rttdelta: 2958782 (srtt 252218) ... ignoring
Bogus rttdelta: 2745782 (srtt 252218) ... ignoring
Bogus rttdelta: 2750782 (srtt 252218) ... ignoring
Bogus rttdelta: 2751782 (srtt 252218) ... ignoring
Bogus rttdelta: 2705782 (srtt 252218) ... ignoring
Bogus rttdelta: 2753782 (srtt 252218) ... ignoring
Bogus rttdelta: 2747782 (srtt 252218) ... ignoring
Bogus rttdelta: 4701810 (srtt 221190) ... ignoring
Bogus rttdelta: 4701810 (srtt 221190) ... ignoring
Bogus rttdelta: 4702810 (srtt 221190) ... ignoring
Bogus rttdelta: 4700810 (srtt 221190) ... ignoring
Bogus rttdelta: 4700810 (srtt 221190) ... ignoring
Bogus rttdelta: 4669810 (srtt 221190) ... ignoring
RTTVAR has grown to over 2.3 seconds, decreasing to 2.0
RTTVAR has grown to over 2.3 seconds, decreasing to 2.0
RTTVAR has grown to over 2.3 seconds, decreasing to 2.0
RTTVAR has grown to over 2.3 seconds, decreasing to 2.0
Completed ARP Ping Scan at 22:24, 18.47s elapsed (1023 total hosts)
Overall sending rates: 108.60 packets / s, 4561.31 bytes / s.
mass_dns: Using DNS server 192.168.51.1
mass_dns: Using DNS server 192.168.51.1
Initiating Parallel DNS resolution of 1023 hosts. at 22:24

C:\Program Files (x86)\Nmap>

[dmiller-nmap]

Thanks for this report. This looks like a crash in Nmap's DNS resolver, likely related to the fact that the DNS servers it is using are on a different interface than the targets being scanned. We may have already resolved this in recent changes, but so that we can be sure, please provide the output of the following commands:

1. nmap -sn -d4 192.168.60.0/22
2. ipconfig /all

If the interface whose address is 192.168.60.1 has a DNS server configured, you can also try adding --dns-servers 192.168.60.XX using that server's address.

[sausix]

Thanks for looking into the issue!

The adapter having 192.168.60.0/22 has no DNS server. Maybe the host itself has a resolver service running due to internet connection sharing. But it should not crash nmap in any case of course.

I did not mention that once the DNS resolver did NOT crash. But only once in 20 tries.

I hope the logs caught a bad run:

nmap.stderr.zip
nmap.stdout.zip
ipconfig.log

[dmiller-nmap]

We are looking for some more diagnostic info to narrow down this crash. Please pass along the following info if you have it:

1. route print
2. powershell -Command "Get-WinEvent -LogName Application | Where-Object { $_.Id -eq 1000 -and $_.Message -like '*nmap.exe*' } | Format-List"
3. Most recent files in %LOCALAPPDATA%\CrashDumps\nmap.exe.*.dump

[sausix]

Here we go. I invoked a scan before collecting the data.

Sorry, output is partially not in english. Don't know how to invoke a process with another locale as it's easy on Linux.

routes.txt
events.txt
nmap.exe.crashdumps.zip

[dmiller-nmap]

The crash dumps show a stack overflow (too many function calls, runaway recursion; NOT a stack buffer overflow). The parallel DNS engine has several places where it initiates new Nsock events from within the event handler of a previous event. This is usually not a problem, since the Nsock events are created in a separate phase from the part of the loop that checks the status and calls the handlers. However, in some cases the event is completed immediately, so the handler is called during the same function call that created the event. This is a more recent change to Nsock, and we've had a couple other bugs related to it.

Here's what I think is happening: Nmap 7.96 introduced changes to allow the parallel DNS resolver to handle forward lookups, which meant we had to track what kind of request was being made (A, AAAA, PTR, etc.). Targets that were not meant to be reverse-resolved (such as those found to be "down") were still in the queue for reverse-DNS, but they had a "NONE" type instead of "PTR." Until recently, each of these resulted in a 0-byte write event. I believe those events were completed immediately, with each one creating a new 0-byte write event from the handler, adding some number of stack frames each time.

The solution is multi-part:

1. NONE-type requests no longer result in 0-byte writes since 2216e38.
2. Connect errors, which often result in immediate completion of the event, are properly handled since a55708b. Previously, a read event was immediately created, which would probably result in more immediate event completions.
3. Read errors are also properly handled: f5a9b18
4. Finally, I moved a line in the write event handler to ensure the same server could not create a new write event for itself from its write handler. This may be too slow, but it does resolve the issue. I will do more performance testing to evaluate this change, which has not yet been synced to Github.