Date: Sun, 16 Oct 2016 13:27:51 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 213527] [patch] [kernel] Rework on functions allocating credentials. Message-ID: <bug-213527-8-LTAypUH71I@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-213527-8@https.bugs.freebsd.org/bugzilla/> References: <bug-213527-8@https.bugs.freebsd.org/bugzilla/>
index | next in thread | previous in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213527 Mateusz Guzik <mjg@FreeBSD.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |mjg@FreeBSD.org CC| |mjg@FreeBSD.org --- Comment #2 from Mateusz Guzik <mjg@FreeBSD.org> --- Hi. The added argument indeed completes part of the task, but the patch is buggy. You consistently have: newcred = crget(p->p_ucred->cr_agroups); PROC_LOCK(p); However, the stability of p_ucred is protected only with the proc lock held. That is, by the time you read the address stored in p->p_ucred, the object stored at that address can be freed. The crget cannot be moved inside because crget can sleep in an unbound manner, while the lock in question disallows that. When dealing with the current process, you can cheat a little and use td->td_ucred as a source for the number of groups. Finally, I would argue crget() interface should be left as it is. Instead, a new function (ncrget?) would be introduced and crget would become a wrapper which uses the current default number of groups as an argument. -- You are receiving this mail because: You are the assignee for the bug.help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-213527-8-LTAypUH71I>
