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

[Ken Raeburn via RT]

[resend; my original message didn't get sent to the submitter]

Begin forwarded message:

> From: Ken Raeburn <raeburn at mit.edu>
> Date: Tue Feb 24, 2004  21:27:48 US/Eastern
> To: rt-comment at krbdev.mit.edu
> Subject: Re: [krbdev.mit.edu #2277] socket leak in sendto_kdc.c, 
> start_connection()
>
> 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
>