Date: Sat, 14 Sep 2002 02:50:13 -0700 (PDT) From: Nate Lawson <nate@root.org> To: current@freebsd.org Subject: patch for lock recursion in execve() Message-ID: <Pine.BSF.4.21.0209140245510.28837-100000@root.org>
next in thread | raw e-mail | index | archive | help
In short: execve has proc lock, calls setugidsafety. If a fd 0...2
references procfs, it is closed via closef(), ... pfs_close(), pfind(),
dopfind() which tries to lock allprocs and then proc
lock. setugidsafety() should drop proc lock or be moved down a few lines
along with fdcheckstd() to be outside of proc lock.
My only concern is if this opens up a race window where fds 0...2 could be
reopened to point to procfs. I'm fairly certain this is not possible but
would like some assurance before committing this.
-Nate
Index: kern_exec.c
===================================================================
RCS file: /home/ncvs/src/sys/kern/kern_exec.c,v
retrieving revision 1.190
diff -u -r1.190 kern_exec.c
--- kern_exec.c 13 Sep 2002 09:31:56 -0000 1.190
+++ kern_exec.c 14 Sep 2002 09:39:41 -0000
@@ -435,15 +435,17 @@
mtx_unlock(&ktrace_mtx);
}
#endif
- /* Close any file descriptors 0..2 that reference procfs
*/
- setugidsafety(td);
/*
- * Make sure file descriptors 0..2 are in use.
+ * Close any file descriptors 0..2 that reference procfs,
+ * then make sure file descriptors 0..2 are in use.
*
+ * setugidsafety() may call closef() and then pfind()
+ * which may grab the process lock and
* fdcheckstd() may call falloc() which may block to
* allocate memory, so temporarily drop the process lock.
*/
PROC_UNLOCK(p);
+ setugidsafety(td);
error = fdcheckstd(td);
PROC_LOCK(p);
if (error != 0)
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0209140245510.28837-100000>