Bug 509716

Summary:	nmap segmentation fault on scan
Product:	[Fedora] Fedora	Reporter:	Michael <midnighterdev>
Component:	nmap	Assignee:	Michal Hlavinka <mhlavink>
Status:	CLOSED ERRATA	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	low
Version:	11	CC:	mhlavink
Target Milestone:	---
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:	5.00-1.fc11	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2009-08-05 00:32:31 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Michael 2009-07-05 13:51:56 UTC

Description of problem:

I get segfault when try scan network with nmap and "-v -sP" arguments.

Version-Release number of selected component (if applicable):

nmap-4.76-4.fc11.x86_64

How reproducible:

always

Steps to Reproduce:
1. su root
2. nmap -v -sP 172.31.176.200/20
3.
  
Actual results:

segmentation fault

Expected results:


Additional info:

[root@localhost midnighter]# gdb nmap
GNU gdb (GDB) Fedora (6.8.50.20090302-32.fc11)
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...

(gdb) run -v -sP 172.31.176.200/20
Starting program: /usr/bin/nmap -v -sP 172.31.176.200/20
[Thread debugging using libthread_db enabled]

Starting Nmap 4.76 ( http://nmap.org ) at 2009-07-05 17:32 MSD
Initiating Ping Scan at 17:32
Scanning 4096 hosts [2 ports/host]

Program received signal SIGSEGV, Segmentation fault.
get_ping_pcap_result (USI=0xedd4a0, stime=<value optimized out>) at scan_engine.cc:4327
4327              if (hss->target->v4hostip()->s_addr == ip->ip_src.s_addr) {

(gdb) thread apply all bt

Thread 1 (Thread 0x7ffff7fc67d0 (LWP 5556)):
#0  get_ping_pcap_result (USI=0xedd4a0, stime=<value optimized out>) at scan_engine.cc:4327
#1  0x00000000004462f1 in waitForResponses (USI=0xedd4a0) at scan_engine.cc:4546
#2  0x0000000000449577 in ultra_scan (Targets=<value optimized out>, ports=<value optimized out>, scantype=<value optimized out>, to=<value optimized out>)
    at scan_engine.cc:4820
#3  0x000000000041d175 in massping (hostbatch=0xadbd70, num_hosts=4096, ports=0x7fffffff9520) at targets.cc:462
#4  0x000000000041d8fd in nexthost (hs=0xad38e0, exclude_group=<value optimized out>, ports=<value optimized out>, pingtype=<value optimized out>)
    at targets.cc:616
#5  0x0000000000419918 in nmap_main (argc=4, argv=<value optimized out>) at nmap.cc:1628
#6  0x0000000000414e4d in main (argc=4, argv=0x7fffffffdf68) at main.cc:224
(gdb) quit

Comment 1 Michal Hlavinka 2009-07-07 12:14:03 UTC

Hi,

I'm not able to reproduce this.

Can you reproduce this always? with any ip/mask set? or even with single ip?

Does your system have more than one nic? Do you have ipv6 enabled or disabled? Do you have any related messages in logs or selinux denials?

Also please verify nmap files are ok:
rpm -V nmap

thanks

Comment 2 Michael 2009-07-07 18:56:17 UTC

Hi. Yes, I can do it only with ip/mask. Not with single ip.

When I do it only with ip/mask, I always have write in "dmesg" like this

nmap[7907]: segfault at 0 ip 0000000000443b5b sp 00007fffa8d69ce0 error 4 in nmap[400000+ad000]

[midnighter@localhost ~]$ ifconfig
eth1      Link encap:Ethernet  HWaddr 00:1F:29:89:B9:98
          inet addr:192.168.10.2  Bcast:192.168.10.255  Mask:255.255.255.0
          inet6 addr: fe80::21f:29ff:fe89:b998/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:880772 errors:0 dropped:0 overruns:0 frame:0
          TX packets:806759 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:845580322 (806.4 MiB)  TX bytes:698270536 (665.9 MiB)
          Memory:e4600000-e4620000

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:90 errors:0 dropped:0 overruns:0 frame:0
          TX packets:90 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:6414 (6.2 KiB)  TX bytes:6414 (6.2 KiB)

virbr0    Link encap:Ethernet  HWaddr FA:C7:F1:32:42:71
          inet addr:192.168.122.1  Bcast:192.168.122.255  Mask:255.255.255.0
          inet6 addr: fe80::f8c7:f1ff:fe32:4271/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:48 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 b)  TX bytes:6993 (6.8 KiB)

I don`t have segmentation fault If I do 

[root@localhost midnighter]# nmap -v -sP 192.168.10.0/24

Starting Nmap 4.76 ( http://nmap.org ) at 2009-07-07 22:39 MSD
Initiating ARP Ping Scan at 22:40                             
Scanning 2 hosts [1 port/host]                                
Completed ARP Ping Scan at 22:40, 0.23s elapsed (2 total hosts)
Initiating Parallel DNS resolution of 2 hosts. at 22:40        
Completed Parallel DNS resolution of 2 hosts. at 22:40, 0.00s elapsed
Host 192.168.10.0 appears to be down.                                
Host 192.168.10.1 appears to be up.                                  
MAC Address: 00:22:15:90:76:27 (Asustek Computer)                    
Initiating Parallel DNS resolution of 1 host. at 22:40               
Completed Parallel DNS resolution of 1 host. at 22:40, 0.01s elapsed 
Host 192.168.10.2 appears to be up.                                  
Initiating ARP Ping Scan at 22:40                                    
Scanning 253 hosts [1 port/host]                                     
ARP Ping Scan Timing: About 40.51% done; ETC: 22:41 (0:00:44 remaining)
Completed ARP Ping Scan at 22:41, 83.22s elapsed (253 total hosts)     
Initiating Parallel DNS resolution of 253 hosts. at 22:41              
Completed Parallel DNS resolution of 253 hosts. at 22:41, 0.13s elapsed
Host 192.168.10.3 appears to be down.                                  
Host 192.168.10.4 appears to be down.                                  
Host 192.168.10.5 appears to be down.                                  
Host 192.168.10.6 appears to be down.                                  
Host 192.168.10.7 appears to be down.                                  
Host 192.168.10.8 appears to be down.                                  
Host 192.168.10.9 appears to be down.                                  
Host 192.168.10.10 appears to be up.                                   
MAC Address: 00:22:15:90:76:27 (Asustek Computer)                      

I think it do because I have NAT

[midnighter@localhost ~]$ traceroute 172.29.0.4
traceroute to 172.29.0.4 (172.29.0.4), 30 hops max, 60 byte packets
 1  192.168.10.1 (192.168.10.1)  0.288 ms  0.223 ms  0.185 ms
 2  172.31.176.2 (172.31.176.2)  76.925 ms  78.803 ms  79.059 ms
 3  core-gw.rusichtvn.ru (172.16.0.2)  2.251 ms  3.451 ms  6.149 ms

192.168.10.2 -> | 192.168.10.1 -NAT- 172.31.176.200 | -> 172.31.176.2 ->...

verify nmap file

[midnighter@localhost ~]$ rpm -V nmap
[midnighter@localhost ~]$

selinux

[root@localhost midnighter]# cat /etc/selinux/config
# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#       enforcing - SELinux security policy is enforced.
#       permissive - SELinux prints warnings instead of enforcing.
#       disabled - SELinux is fully disabled.
SELINUX=disabled
# SELINUXTYPE= type of policy in use. Possible values are:
#       targeted - Only targeted network daemons are protected.
#       strict - Full SELinux protection.
SELINUXTYPE=targeted

Comment 3 Michal Hlavinka 2009-07-13 14:42:52 UTC

I've tried this several times (with nat and without nat, with ipv6 on/off,...), but with no success. Could you test new (beta) nmap version? I'll prepare package, if so.

Comment 4 Michael 2009-07-13 17:16:39 UTC

Yes, I'll want to test it. Give me it package.

Comment 5 Michal Hlavinka 2009-07-14 07:22:04 UTC

64b packages can be found here:

http://koji.fedoraproject.org/koji/taskinfo?taskID=1472673

Comment 6 Michael 2009-07-14 18:58:54 UTC

I have not segmentation fault with "nmap-4.90-0.fc11.RC1.0.rhbz509716.1.x86_64.rpm" package. Thanks.

Comment 7 Fedora Update System 2009-07-16 08:21:14 UTC

nmap-4.90-0.RC1.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/nmap-4.90-0.RC1.fc11

Comment 8 Fedora Update System 2009-07-19 10:24:50 UTC

nmap-4.90-0.RC1.fc11 has been pushed to the Fedora 11 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update nmap'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-7766

Comment 9 Fedora Update System 2009-07-20 07:21:26 UTC

nmap-5.00-1.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/nmap-5.00-1.fc11

Comment 10 Fedora Update System 2009-07-22 22:07:55 UTC

nmap-5.00-1.fc11 has been pushed to the Fedora 11 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update nmap'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-7916

Comment 11 Fedora Update System 2009-08-05 00:32:27 UTC

nmap-5.00-1.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.