[krbdev.mit.edu #2277] socket leak in sendto_kdc.c, start_connection()

[Ken Raeburn via RT]

On Tuesday, Feb 24, 2004, at 18:56 US/Eastern, Bill Dodd via RT wrote:

> In start_connection(), if the connect() fails (e.g. with ECONNREFUSED),
> an error is returned, but the socket is not closed.

Under what circumstances (aside from, maybe, running the client and KDC 
on the same host) can you get back ECONNREFUSED from a connect call on 
a non-blocking socket?  Seems to me that to get and process the ICMP 
message from another host, the process would have to, well, block.  I 
suppose, if the scheduler switched to another process during the 
connect call, it's possible a response from another nearby host could 
come in before the process continued, but it seems like a tricky race 
condition more than a reliable leak.

It's definitely a bug, I'm just trying to get a sense of how serious...

> To observe the leak, set udp_preference_limit to 1 in krb5.conf and
> run kdc5_hammer with a large repeat count against a kdc that only
> listens on UDP. Observe the open files/sockets with lsof. A contrived
> scenario to be sure, but it can be seen in more legitimate cases as
> well.

Were you testing this with a KDC on the same host, or another host?

Ken