
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:
- [RFC] Nsock connect error handling Daniel Miller (Mar 16)
- Re: [RFC] Nsock connect error handling David Fifield (Mar 16)
- Re: [RFC] Nsock connect error handling Daniel Miller (Mar 20)
- Re: [RFC] Nsock connect error handling David Fifield (Mar 16)