Fwd: Patches for NMAP-6.01

[Bill Parker <wp02855 () gmail com>]

---------- Forwarded message ----------
From: Bill Parker <wp02855 () gmail com>
Date: Mon, Nov 12, 2012 at 9:51 AM
Subject: Re: Patches for NMAP-6.01
To: David Fifield <david () bamsoftware com>


Thanks for the quick reply...on the socklen_t issue, it doesn't cause a
issue on
every platform, but from my observation, some platforms are just more picky
than others.  The libpcap stuff is in work, it just takes them a while to
get around
to applying the patches i've submitted in GitHub.

I will go ahead and resend this to nmap-dev () insecure org per your request,
that way people can look at/comment/modify what they like. :)

Bill


On Mon, Nov 12, 2012 at 9:48 AM, David Fifield <david () bamsoftware com>wrote:

> On Mon, Nov 12, 2012 at 09:35:16AM -0800, Bill Parker wrote:
> >    In reviewing code in NMAP-6.01, I found various calls to
> > malloc()/calloc()/realloc() which were not being checked
> > for a return value of NULL which would indicate failure.
> >
> > In addition, I also found deprecated calls to bzero() which
> > were replaced by memset() which is ANSI/ISO compliant, a
> > call to read() which isn't checked for failure, and added
> > a warning message in the event the call to munmap() cannot
> > unmap the memory location in question.
> >
> > In directory nmap-6.01/libpcap, file 'pcap-sita.c', several
> > of these calls were found, and code was added to check
> > for return values of NULL.  Additionally, the deprecated
> > calls to bzero() were replaced with memset().  The patch file
> > listing is below:
>
> Hello Bill,
>
> I'd like to ask you to resubmit this message to the
> nmap-dev () insecure org mailing list. This is the place where we do
> discussion of new patches.
>
> My general comments: Changes to libdnet are acceptable. They should not
> be doing an fprintf when an error is detected, rather try to find an
> appropriate return code. Changes to libpcap need to be submitted
> upstream because we don't maintain changes to that library. Personally I
> don't see a reason to replace bzero with memset as long as it's not
> causing problems. Does the lack of a socklen_t * cast cause a
> compilation warning?
>
> It's easier for us to apply the patches if you keep the full path names
> in them.
>
> David Fifield
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/