--excludefile causing reads in free()'d memory

[Brandon Enright <bmenrigh () ucsd edu>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

While troubleshooting some other issues, I noticed that Valgrind
complains with the following error when I use the --excludefile option:

==12717== Invalid read of size 1
==12717==    at 0x646547C: strtok (in /lib64/libc-2.6.1.so)
==12717==    by 0x421E54: load_exclude(_IO_FILE*, char*) (targets.cc:333)
==12717==    by 0x41E9AE: nmap_main(int, char**) (nmap.cc:1576)
==12717==    by 0x419EA6: main (main.cc:224)
==12717==  Address 0x76aa216 is 14 bytes inside a block of size 15 free'd
==12717==    at 0x4C210AA: free (in /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so)
==12717==    by 0x456732: TargetGroup::parse_expr(char const*, int) (TargetGroup.cc:318)
==12717==    by 0x421E7A: load_exclude(_IO_FILE*, char*) (targets.cc:328)
==12717==    by 0x41E9AE: nmap_main(int, char**) (nmap.cc:1576)
==12717==    by 0x419EA6: main (main.cc:224)


The offending code appears to be targets.cc:328 and targets.cc:333

      pc=strtok(acBuf, "\t\n ");

      while ((char *)0 != pc) {
         if(excludelist[i].parse_expr(pc,o.af()) == 0) {
           if (o.debugging > 1)
             error("Loaded exclude target of: %s", pc);
           ++i;
         }
         pc=strtok(NULL, "\t\n ");
      }
    }


Valgrind seems to think that parse_expr(pc,o.af()) is causing some
memory to be freed that is being read by the subsequent call to
pc=strtok(NULL, "\t\n ");

I've looked at TargetGroup::parse_expr but it immediately does a
strdup() and only frees that.

I'm going to generate a suppression for this problem and move on with
my troubleshooting but I figure someone is going to want to look at the
code in-depth to figure out what is going on.

Brandon

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkmwM+8ACgkQqaGPzAsl94LCPgCeKZG7hIbdwv5kaAPUEBeO+OhS
g7cAn0os00shZIB+ioJ73+QhbQtuHOIu
=32Dh
-----END PGP SIGNATURE-----

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