Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!simtel!zombie.ncsc.mil!news.mathworks.com!newsfeed.internetmci.com!news.mid.net!sbctri.tri.sbc.com!newspump.wustl.edu!newsreader.wustl.edu!guardian.EnGarde.com!guardian.EnGarde.com!not-for-mail
From: mcn@EnGarde.com (Mike Neuman)
Newsgroups: comp.bugs.4bsd
Subject: Bug in 4.4BSD inetd
Date: 11 Oct 1995 09:40:23 -0500
Organization: En Garde Systems--St. Louis, MO
Lines: 46
Message-ID: <45gl0n$n96@guardian.EnGarde.com>
Reply-To: mcn@EnGarde.com
NNTP-Posting-Host: @dialin-38.wustl.edu
While playing with 4.4's inetd and tcpmux this week, I found the following
bug:
(starting around line 314 or so, inetd.c):
for (sep = servtab; n && sep; sep = sep->se_next)
...
if (sep->se_bi && sep->se_bi->bi_fn == (void (*)()) tcpmux) {
sep = tcpmux(ctrl);
if (sep==NULL) {
close(ctrl);
continue;
}
}
It turns out, if tcpmux fails, and returns a NULL, continue will cause a
sep=sep->se_next which causes a segmentation fault. This can be proven by
entering any unknown service into tcpmux.
Anyway, here's the context diffs:
*** inetd.c.old Wed Oct 11 09:34:31 1995
--- inetd.c Wed Oct 11 09:34:57 1995
***************
*** 337,343 ****
sep = tcpmux(ctrl);
if (sep == NULL) {
close(ctrl);
! continue;
}
}
} else
--- 337,343 ----
sep = tcpmux(ctrl);
if (sep == NULL) {
close(ctrl);
! break;
}
}
} else
======Cut here=====
-Mike Neuman
mcn@EnGarde.com
En Garde Systems