From owner-freebsd-security Wed Dec 23 00:55:09 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA15683 for freebsd-security-outgoing; Wed, 23 Dec 1998 00:55:09 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA15667 for ; Wed, 23 Dec 1998 00:55:07 -0800 (PST) (envelope-from peter.jeremy@auss2.alcatel.com.au) Received: by border.alcanet.com.au id <40360>; Wed, 23 Dec 1998 19:54:10 +1100 Date: Wed, 23 Dec 1998 19:54:54 +1100 From: Peter Jeremy Subject: Re: cvs commit: src/etc rc.conf To: freebsd-security@FreeBSD.ORG Cc: dillon@apollo.backplane.com Message-Id: <98Dec23.195410est.40360@border.alcanet.com.au> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Matthew Dillon wrote: >:The BSD book describes a bug in the mark and sweep garbage collection >:algorithm than can result in file descriptor hijacking or kernel memory >:nasties. Does anyone know if this was ever fixed? (It is discussed in >:the 4.4BSD book in a footnote on the page that discusses SCM_RIGHTS) I >:glanced through the code for a while this summer while I was modifying the >:SCM_ ancillary data passing code to be hookable by an LKM. My goal was to >:... > > I have no idea.... what does the footnote say exactly? At the bottom of page 389: "If a listening socket is accessible, then any queued connections that it holds are also accessible; the garbage collector in 4.4BSD fails to take this into account." This footnote is referenced from a paragraph discussing unp_gc() - which can be found in kern/uipc_usrreq.c. From a quick look at the 2.2.6 CVS logs (the latest I can quickly study), it doesn't look like it's ever been eradicated. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message