From owner-freebsd-security Sun May 9 7: 7:39 1999 Delivered-To: freebsd-security@freebsd.org Received: from gatekeeper.tsc.tdk.com (gatekeeper.tsc.tdk.com [207.113.159.21]) by hub.freebsd.org (Postfix) with ESMTP id 59E4D154DF for ; Sun, 9 May 1999 07:07:34 -0700 (PDT) (envelope-from gdonl@tsc.tdk.com) Received: from sunrise.gv.tsc.tdk.com (root@sunrise.gv.tsc.tdk.com [192.168.241.191]) by gatekeeper.tsc.tdk.com (8.8.8/8.8.8) with ESMTP id HAA12452; Sun, 9 May 1999 07:06:09 -0700 (PDT) (envelope-from gdonl@tsc.tdk.com) Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194]) by sunrise.gv.tsc.tdk.com (8.8.5/8.8.5) with ESMTP id HAA16187; Sun, 9 May 1999 07:06:08 -0700 (PDT) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id HAA20815; Sun, 9 May 1999 07:06:07 -0700 (PDT) From: Don Lewis Message-Id: <199905091406.HAA20815@salsa.gv.tsc.tdk.com> Date: Sun, 9 May 1999 07:06:07 -0700 In-Reply-To: Don Lewis "Re: KKIS.05051999.003b" (May 9, 6:48am) X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: Don Lewis , sthaug@nethelp.no Subject: Re: KKIS.05051999.003b Cc: wes@softweyr.com, toasty@HOME.DRAGONDATA.COM, security@FreeBSD.ORG Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On May 9, 6:48am, Don Lewis wrote: } Subject: Re: KKIS.05051999.003b } FLASH! Now this is really wierd. The original exploit code doesn't show } any signs leaking descriptors on one of our 3.1-stable machines, but } /tmp (where the sockets are created) is mfs. If I change PATH and } PATH_TMP so that they point to /var/tmp, sendmsg() fails with with } ECONNREFUSED after the first iteration and descriptors are leaked. } } I might believe that descriptors could be leaked if sendmsg() fails this } way, but why would sendmsg() fail if the sockets live in a ufs filesystem } but not if the sockets live in a mfs filesystem? Ok, the first bug is in uipc_send(). If an error occurs between unp_internalize() and release:, then the work that unp_internalize() did needs to be undone. Probably something like: if (control && error != 0) unp_dispose(control); right before release: would do the trick. I haven't a clue about what appears to be bug number 2. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message