Re: [RFC] Nsock connect error handling

[Daniel Miller <bonsaiviking () gmail com>]

Thanks for confirming, David. I committed this change in r36653.

Dan

On Thu, Mar 16, 2017 at 10:44 PM, David Fifield <david () bamsoftware com>
wrote:

> On Thu, Mar 16, 2017 at 10:37:51PM -0500, Daniel Miller wrote:
> > I was just looking at a bug report [1] that showed that an ICMP Type 12
> > (Parameter Problem) packet could cause Nsock to throw a fatal error.
> Timed just
> > right, this could crash Nmap during version scan. The fix is simple: add
> EPROTO
> > to the long list of known error codes in handle_connect_result [2]. But
> is that
> > the best option?
> >
> > As far as I can tell, there is no reason for Nsock to be checking for
> specific
> > error codes. The action is always the same: return a Nsock error and set
> the
> > error code appropriately. The only non-error condition is explicitly
> handled:
> > connect() returns 0, and Nsock returns success. Why can't we make the
> default
> > case handle any error code possible?
>
> I think you're right on both counts. You can fix the bug by adding
> EPROTO to the list of known errors. And, the default error case could be
> made to handle any error generically.
> _______________________________________________
> Sent through the dev mailing list
> https://nmap.org/mailman/listinfo/dev
> Archived at http://seclists.org/nmap-dev/
_______________________________________________
Sent through the dev mailing list
https://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/