Channel leak problem in res_send()

Jeff Schreiber schreiber at process.com
Thu Dec 21 17:54:27 UTC 2000


    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




More information about the bind-workers mailing list