Nmap Development mailing list archives

Re: memcpy overlap in getinterfaces(int*) (tcpip.cc:2987)


From: Patrick Donnelly <batrick () batbytes com>
Date: Tue, 16 Jun 2009 16:30:20 -0600

Hi Brandon,

On Tue, Jun 16, 2009 at 4:07 PM, Brandon Enright<bmenrigh () ucsd edu> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I was recently testing Nmap in Valgrind and noticed that I always get
the following warning:

==20569== Source and destination overlap in memcpy(0x7FEFFA160, 0x7FEFFA160, 16)
==20569==    at 0x4C2590A: memcpy (in /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so)
==20569==    by 0x453AB7: getinterfaces(int*) (tcpip.cc:2987)
==20569==    by 0x454ADD: route_dst(sockaddr_storage const*, route_nfo*) (tcpip.cc:3376)
==20569==    by 0x452201: nexthost(HostGroupState*, TargetGroup*, scan_lists*, int) (targets.cc:492)
==20569==    by 0x44DE72: nmap_main(int, char**) (nmap.cc:1722)
==20569==    by 0x446152: main (main.cc:215)
==20569==

Valgrind is (rightfully) complaining that the source and destination
address are the same to a call to memcpy().  In looking at the code, it
seems that they will often be the same:

Starting at tcpip.cc:2977

       sin = (struct sockaddr_in *) &(tmpifr.ifr_addr); /* ifr_netmask only on Linux */
       addr_stob(&(tmpifr.ifr_addr), &mydevs[numifaces].netmask_bits);
     }

...comments...

     Strncpy(tmpifr.ifr_name, ifr->ifr_name, sizeof(tmpifr.ifr_name));
     memcpy(&(tmpifr.ifr_addr), sin, MIN(sizeof(tmpifr.ifr_addr), sizeof(*sin)\));

Does anybody have any ideas about the right way to fix this code?
Should we just drop the call to memcpy?

Brandon


I don't know what the intent of this code is but generally you fix
this by using memmove() instead of memcpy() when the memory blocks
overlap at all.

-- 
-Patrick Donnelly

"Let all men know thee, but no man know thee thoroughly: Men freely
ford that see the shallows."

- Benjamin Franklin

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org

Current thread: