Date: Tue, 20 Dec 2011 09:00:39 -0500 From: John Baldwin <jhb@freebsd.org> To: freebsd-current@freebsd.org Cc: Rick Macklem <rmacklem@uoguelph.ca> Subject: Re: making crdup()/crcopy() safe?? Message-ID: <201112200900.39087.jhb@freebsd.org> In-Reply-To: <261812530.427572.1324344105125.JavaMail.root@erie.cs.uoguelph.ca> References: <261812530.427572.1324344105125.JavaMail.root@erie.cs.uoguelph.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201112200900.39087.jhb>