From owner-freebsd-bugs Sat Jan 19 15:15:30 2002 Delivered-To: freebsd-bugs@freebsd.org Received: from math.psu.edu (leibniz.math.psu.edu [146.186.130.2]) by hub.freebsd.org (Postfix) with ESMTP id 7DFF437B405; Sat, 19 Jan 2002 15:15:25 -0800 (PST) Received: from weyl.math.psu.edu (weyl.math.psu.edu [146.186.130.226]) by math.psu.edu (8.9.3/8.9.3) with ESMTP id SAA08409; Sat, 19 Jan 2002 18:15:20 -0500 (EST) Received: from localhost (viro@localhost) by weyl.math.psu.edu (8.9.3/8.9.3) with ESMTP id SAA05560; Sat, 19 Jan 2002 18:15:20 -0500 (EST) X-Authentication-Warning: weyl.math.psu.edu: viro owned process doing -bs Date: Sat, 19 Jan 2002 18:15:20 -0500 (EST) From: Alexander Viro To: iedowse@FreeBSD.org Cc: freebsd-bugs@FreeBSD.org Subject: Re: kern/8498: Race condition between unp_gc() and accept(). In-Reply-To: <200201192247.g0JMlQh78530@freefall.freebsd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sat, 19 Jan 2002 iedowse@FreeBSD.org wrote: > Synopsis: Race condition between unp_gc() and accept(). > > State-Changed-From-To: open->feedback > State-Changed-By: iedowse > State-Changed-When: Sat Jan 19 14:47:11 PST 2002 > State-Changed-Why: > > Does this problem still exist? As far as I can see it's still there in HEAD - analysis from the original bug report still applies. BTW, there is another problem: uipc_userreq.c:1378 has extra_ref = malloc(nfiles * sizeof(struct file *), M_FILE, M_WAITOK); which can block. During that time we might get new files opened and sent in SCM_RIGHTS cookies. Notice that a) we will have them _not_ marked, so the code after that will try to kill them. b) nfiles might have grown! The former means that legitimate stuff gets killed. The latter is a buffer overrun in kernel space waiting to happen. Fix: invert the logics with "marked". I.e. start with marking everything, then unmark those you want to stay around. Then by the end of the first phase you have marked exactly the stuff that needs to die. New struct file won't be marked, so the loop populating extra_ref will skip it... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message