Nmap Development mailing list archives

[RFC] Nsock connect error handling


From: Daniel Miller <bonsaiviking () gmail com>
Date: Thu, 16 Mar 2017 22:37:51 -0500

List,

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?

The code contains the comment /* I'd like for someone to report it */, but
that's been in there since Nsock was created, back in 2000. Maybe Fyodor
can comment on the original intent?

Dan
_______________________________________________
Sent through the dev mailing list
https://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/

Current thread: