Repository navigation
nmap 7.97 crash: DNS queries to unrelated DNS server #3130
Description
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>
Activity
dmiller-nmap commentedon Jun 9, 2025
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:
nmap -sn -d4 192.168.60.0/22ipconfig /allIf the interface whose address is 192.168.60.1 has a DNS server configured, you can also try adding
--dns-servers 192.168.60.XXusing that server's address.[-]nmap DNS queries to unrelated DNS server vanishes ping scan results completly[/-][+]nmap 7.97 crash: DNS queries to unrelated DNS server[/+]sausix commentedon Jun 10, 2025
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 commentedon Jun 26, 2025
We are looking for some more diagnostic info to narrow down this crash. Please pass along the following info if you have it:
route printpowershell -Command "Get-WinEvent -LogName Application | Where-Object { $_.Id -eq 1000 -and $_.Message -like '*nmap.exe*' } | Format-List"%LOCALAPPDATA%\CrashDumps\nmap.exe.*.dumpsausix commentedon Jun 28, 2025
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 commentedon Jun 30, 2025
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:
Hedge against runaway recursion. See #3130
Avoid runaway recursion in service scan, similar to #3130