Channel leak problem in res_send()

[Mark.Andrews at nominum.com]

	It looks like the correct fix.

	Mark

>     Forwarding for a co-worker who is working this problem while I'm on
>     vacation.
> 
>                                                 -Jeff Schreiber
> 
> Richard Whalen <Whalenr at process.com> writes:
> >
> >The changes are as follows:
> >In res_send.c, routine res_nsend
> >change
> >	if (needclose)
> >	    res_nclose(statp);
> >to
> >	if (needclose) {
> >	   res_nclose(statp);
> >	   EXT(statp).nscount = 0;
> >	   }
> >
> >in res_init.c, routine res_nclose
> >remove
> >	statp->_u._ext.nscount = 0;
> >which is the last statement in the routine. (note that this the same as
> >EXT(statp).nscount, they are just written differently in different places.)
> >
> >The reason for the change is that the code can call send_dg after calling
> >res_nclose when certain conditions exist.  Since (the unchanged) res_nclose
> >zeros the limit value in its for loop when it finishes, subsequent calls to
> >res_nclose that result from the same call to res_nsend will not close the
> >sockets to the nameservers.  Since res_nsend was using EXT(statp).nscount ==
> >0 as the way of determining that the list needs to be initialized, the
> >zeroing of this is put in the code that detects that it should be refreshed.
> >
> >We have a question though as to whether or not this change fits with the
> >intent of the code when it was written, as the same effect could be obtained
> >by changing the for loop in res_nclose to use statp->nscount as the limit.
> >Since res_nsend goes to the trouble of copying the list (and the count of
> >elements) at the beginning it looks like there is an attempt to insulate the
> >task from any potential changes to statp.nscount while a name is being
> >resolved, which is why the first change that is mentioned is a possibility.
> >Changing the limit of the for loop in res_nclose is a possibility if the
> >intended use of statp->_u._ext.nscount was to keep a count the number of
> >sockets open to name servers.  Note that changing the for loop to use
> >statp->nscount as the limit could cause problems if this value decreases
> >during the process of resolving a name, in which case I would suggest using
> >MAXNS as the limit, though this would cause much more than necessary of the
> >array to be checked.
> >
> 
> --
> Jeff Schreiber,            Process Software LLC
> schreiber at mx.process.com   http://www.process.com
>    TCPware, MultiNet & PMDF: Stronger than Ever
> 
> 
> 
--
Mark Andrews, Nominum Inc.
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark.Andrews at nominum.com