inetd bug

Cathey, Jim jcathey at ciena.com
Wed Nov 5 17:47:50 UTC 2008


On the face of it I think this fix is inadequate,
given that "maxsock + 1" is used in the select().
With no services, should select not have a 0 as the
first argument, thus requiring maxsock to be -1 and
not 0?  All the problems fell out of that value.

-- Jim



-----Original Message-----
From: Denys Vlasenko [mailto:vda.linux at googlemail.com] 
Sent: Wednesday, November 05, 2008 3:37 AM
To: wharms at bfs.de
Cc: Cathey, Jim; busybox at busybox.net
Subject: Re: inetd bug

> Cathey, Jim schrieb:
>> We've been using BB, and found that when we had an /etc/inetd.conf
>> file with only one service in it, said service being commented in
>> and out as it was enabled/disabled by the system (along with a HUP
>> to inetd), that the lone service could not re-enable.  I tracked it
>> down to a bug where the maxsock variable wasn't being used correctly.

Can you explain where exactly that failed? Form what I can see,
the only erroneous place is this one (fix is shown too):

 static void recalculate_maxsock(void)
 {
        int fd = 0;
+       maxsock = 0;
        while (fd <= prev_maxsock) {
                if (FD_ISSET(fd, &allsock))
                        maxsock = fd;

Basically, if there are no services at all, maxsock was not updated
and stayed -1, the rest of code was not expecting that can ever happen
after recalculate_maxsock().

Am I right in my analysis or are there other places where code is wrong?
IOW, does the above fix work for you?
--
vda




More information about the busybox mailing list