From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 14:09:00 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 40D841065675 for ; Tue, 20 Dec 2011 14:09:00 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 17EE48FC12 for ; Tue, 20 Dec 2011 14:09:00 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id C45FA46B06; Tue, 20 Dec 2011 09:08:59 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 33F25B93E; Tue, 20 Dec 2011 09:08:59 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Date: Tue, 20 Dec 2011 09:00:39 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: <261812530.427572.1324344105125.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <261812530.427572.1324344105125.JavaMail.root@erie.cs.uoguelph.ca> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201112200900.39087.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 20 Dec 2011 09:08:59 -0500 (EST) Cc: Rick Macklem Subject: Re: making crdup()/crcopy() safe?? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 14:09:00 -0000 On Monday, December 19, 2011 8:21:45 pm Rick Macklem wrote: > Hi, > > A recent NFS client crash: > http://glebius.int.ru/tmp/nfs_panic.jpg > appears to have happened because some field is > bogus when crfree() is called. I've asked Gleb > to disassemble crfree() for me, so I can try and > see exactly which field causes the crash, however... > > Basically, the code: > newcred = crdup(cred); > - does read with newcred > crfree(newcred); <-- which crashes at 0x65 into > crfree() > > Looking at crdup(), it calls crcopy(), which copies > 4 pointers and then ref. counts them: > cr_uidinfo, cr_ruidinfo, cr_prison and cr_loginclass > > It seems some lock should be held while crcopy() does this, > so that the pointers don't get deref'd during the copy/ref. count? > (Or is there some rule that guarantees these won't change. ie. No > no calls to change_euid() or similar.) > > Is there such a lock and should crdup() use it? In general the caller of crdup is expected to hold a reference on cred or some other lock to ensure that cred remains valid and cannot be free'd while it is being duplicated. There is no global lock that crdup can hold for that, instead the caller is required to guarantee that. -- John Baldwin