valgrind complains on uninitialised bytes

[Vasily Kulikov <segoon () openwall com>]

vasya@cachalot:~/dev/nmap/nmap$ sudo valgrind ./nmap -sS 192.168.1.1
==21148== Memcheck, a memory error detector
==21148== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==21148== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==21148== Command: ./nmap -sS 192.168.1.1
==21148== 

Starting Nmap 6.41SVN ( http://nmap.org ) at 2013-08-13 12:08 MSK
==21148== Syscall param socketcall.setsockopt(optval) points to uninitialised byte(s)
==21148==    at 0x65F5F0A: setsockopt (syscall-template.S:82)
==21148==    by 0x50758F9: ??? (in /usr/lib/x86_64-linux-gnu/libpcap.so.1.1.1)
==21148==    by 0x507722D: ??? (in /usr/lib/x86_64-linux-gnu/libpcap.so.1.1.1)
==21148==    by 0x4C1BB6: set_pcap_filter(char const*, pcap*, char const*, ...) (netutil.cc:4061)
==21148==    by 0x47F145: ultra_scan(std::vector<Target*, std::allocator<Target*> >&, scan_lists*, stype, 
timeout_info*) (scan_engine.cc:5560)
==21148==    by 0x491876: arpping(Target**, int) (targets.cc:176)
==21148==    by 0x491D58: nexthost(HostGroupState*, addrset const*, scan_lists*, int) (targets.cc:666)
==21148==    by 0x44D07D: nmap_main(int, char**) (nmap.cc:1852)
==21148==    by 0x42AFD4: main (main.cc:229)
==21148==  Address 0x7feffe3d2 is on thread 1's stack
==21148== 
Nmap scan report for Broadcom.Home (192.168.1.1)
Host is up (0.0050s latency).
Not shown: 992 filtered ports
PORT     STATE  SERVICE
25/tcp   closed smtp
53/tcp   closed domain
111/tcp  closed rpcbind
445/tcp  closed microsoft-ds
1025/tcp closed NFS-or-IIS
3389/tcp closed ms-wbt-server
5900/tcp closed vnc
8888/tcp closed sun-answerbook
MAC Address: 20:4E:7F:CF:1B:C4 (Netgear)

Nmap done: 1 IP address (1 host up) scanned in 7.02 seconds
==21148== 
==21148== HEAP SUMMARY:
==21148==     in use at exit: 2,218,028 bytes in 26 blocks
==21148==   total heap usage: 88,981 allocs, 88,955 frees, 7,275,852 bytes allocated
==21148== 
==21148== LEAK SUMMARY:
==21148==    definitely lost: 60 bytes in 1 blocks
==21148==    indirectly lost: 240 bytes in 10 blocks
==21148==      possibly lost: 0 bytes in 0 blocks
==21148==    still reachable: 2,217,728 bytes in 15 blocks
==21148==         suppressed: 0 bytes in 0 blocks
==21148== Rerun with --leak-check=full to see details of leaked memory
==21148== 
==21148== For counts of detected and suppressed errors, rerun with: -v
==21148== Use --track-origins=yes to see where uninitialised values come from
==21148== ERROR SUMMARY: 2 errors from 1 contexts (suppressed: 2 from 2)
vasya@cachalot:~/dev/nmap/nmap$ svn info
Path: .
URL: https://svn.nmap.org/nmap
Repository Root: https://svn.nmap.org
Repository UUID: e0a8ed71-7df4-0310-8962-fdc924857419
Revision: 31783
Node Kind: directory
Schedule: normal
Last Changed Author: d33tah
Last Changed Rev: 31750
Last Changed Date: 2013-08-12 00:52:15 +0400
vasya@cachalot:~/dev/nmap/nmap$ valgrind --version
valgrind-3.7.0

vasya@cachalot:~/dev/nmap/nmap$ dpkg -l 'libpcap*'
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name                         Version                      Description
+++-============================-============================-========================================================================
un  libpcap-dev                  <none>                       (no description available)
un  libpcap0.7-dev               <none>                       (no description available)
ii  libpcap0.8                   1.1.1-10                     system interface for user-level packet capture
ii  libpcap0.8-dev               1.1.1-10                     development library and header files for libpcap0.8


With --with-libpcap=included the bug is gone.  Is it a bug in Ubuntu's
version of libpcap or in the nmap's way of libpcap's usage?

Thanks,

-- 
Vasily Kulikov
http://www.openwall.com - bringing security into open computing environments
_______________________________________________
Sent through the dev mailing list
http://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/