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
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
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
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.
Yes, I'll want to test it. Give me it package.
64b packages can be found here: http://koji.fedoraproject.org/koji/taskinfo?taskID=1472673
I have not segmentation fault with "nmap-4.90-0.fc11.RC1.0.rhbz509716.1.x86_64.rpm" package. Thanks.
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
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
nmap-5.00-1.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/nmap-5.00-1.fc11
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
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.