From nobody@FreeBSD.org  Tue Oct 26 15:26:36 2010
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 984081065698
	for <freebsd-gnats-submit@FreeBSD.org>; Tue, 26 Oct 2010 15:26:36 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21])
	by mx1.freebsd.org (Postfix) with ESMTP id 875738FC14
	for <freebsd-gnats-submit@FreeBSD.org>; Tue, 26 Oct 2010 15:26:36 +0000 (UTC)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.14.3/8.14.3) with ESMTP id o9QFQZat051104
	for <freebsd-gnats-submit@FreeBSD.org>; Tue, 26 Oct 2010 15:26:35 GMT
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.14.3/8.14.3/Submit) id o9QFQZFF051101;
	Tue, 26 Oct 2010 15:26:35 GMT
	(envelope-from nobody)
Message-Id: <201010261526.o9QFQZFF051101@www.freebsd.org>
Date: Tue, 26 Oct 2010 15:26:35 GMT
From: Andrey Shidakov <andrey@shidakov.ru>
To: freebsd-gnats-submit@FreeBSD.org
Subject: tmux kernel panic, with out root privilegies
X-Send-Pr-Version: www-3.1
X-GNATS-Notify:

>Number:         151758
>Category:       kern
>Synopsis:       [panic] tmux kernel panic, with out root privilegies
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    jhb
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Oct 26 15:30:14 UTC 2010
>Closed-Date:    Thu Jan 05 19:39:19 UTC 2012
>Last-Modified:  Thu Jan 05 19:39:19 UTC 2012
>Originator:     Andrey Shidakov
>Release:        FreeBSD 8.1
>Organization:
>Environment:
FreeBSD nixadm.ru 8.1-STABLE FreeBSD 8.1-STABLE #3 r214232M: Sat Oct 23 12:12:05 MSD 2010     root@nixadm.ru:/usr/obj/usr/src/sys/mr-krabe  i386

>Description:
tmux, installed from ports, causes kernel panic. Even runned from user,
not root.

>How-To-Repeat:
1. Install from ports tmux (latest version 1.3). 
2. Run: 
$ tmux list-commands 
(konsole hangs)
3. Run in another console 
$ killall -9 tmux

4. System halted with kernel panic.

>Fix:


>Release-Note:
>Audit-Trail:

From: Remko Lodder <remko@elvandar.org>
To: Andrey Shidakov <andrey@shidakov.ru>
Cc: freebsd-gnats-submit@FreeBSD.org
Subject: Re: i386/151758: tmux kernel panic, with out root privilegies
Date: Tue, 26 Oct 2010 19:00:17 +0200

 Most likely this is a ports problem, but still, try to get a dump that =
 we can investigate. IF that informs us about issues with the system, we =
 might have a look at that
 (given that that might be because of a system problem instead of a tmux =
 problem).
 
 Thanks,
 Remko
 
 
 --=20
 /"\   Best regards,                        | remko@FreeBSD.org
 \ /   Remko Lodder                      | remko@EFnet
 X    http://www.evilcoder.org/    | Quis custodiet ipsos custodes
 / \   ASCII Ribbon Campaign    | Against HTML Mail and News
 
 
 
Responsible-Changed-From-To: freebsd-i386->freebsd-bugs 
Responsible-Changed-By: linimon 
Responsible-Changed-When: Fri Nov 5 11:10:15 UTC 2010 
Responsible-Changed-Why:  
This does not sound i386-specific. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=151758 

From: Ruben van Staveren <ruben@verweg.com>
To: bug-followup@FreeBSD.org, andrey@shidakov.ru
Cc:  
Subject: Re: kern/151758: [panic] tmux kernel panic, with out root privilegies
Date: Sun, 27 Feb 2011 20:38:53 +0100

 Had this on a FreeBSD chassis 8.2-RELEASE FreeBSD 8.2-RELEASE #3: Fri =
 Feb 25 15:44:51 CET 2011     =
 root@chassis:/opt/obj/usr/cvsup/8-stable/src/sys/CHASSIS  amd64 system
 
 
 Stack trace likely to be incomplete, second in a row. previous panic was =
 with RELENG_8_1 prior to the reboot (so had most of 8.2 already =
 installed)
 
 Fatal trap 12: page fault while in kernel mode
 cpuid =3D 1; apic id =3D 01
 fault virtual address   =3D 0x250
 fault code              =3D supervisor read data, page not present
 instruction pointer     =3D 0x20:0xffffffff8034a584
 stack pointer           =3D 0x28:0xffffff80886e2820
 frame pointer           =3D 0x28:0xffffff80886e2840
 code segment            =3D base 0x0, limit 0xfffff, type 0x1b
                         =3D DPL 0, pres 1, long 1, def32 0, gran 1
 processor eflags        =3D interrupt enabled, resume, IOPL =3D 0
 current process         =3D 79289 (tmux)
 trap number             =3D 12
 panic: page fault
 cpuid =3D 1
 KDB: stack backtrace:
 db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
 kdb_backtrace() at kdb_backtrace+0x37
 panic() at panic+0x187
 trap_fatal() at trap_fatal+0x290
 trap_pfault() at trap_pfault+0x2fd
 trap() at trap+0x343
 calltrap() at calltrap+0x8
 --- trap 0xc, rip =3D 0xffffffff8034a584, rsp =3D 0xffffff80886e2820, =
 rbp =3D 0xffffff80886e2840 ---
 devfs_close_f() at devfs_close_f+0x14
 _fdrop() at _fdrop+0x23
 closef() at closef+0x45
 unp_scan() at unp_scan+0xd7
 sofree() at sofree+0x122
 soclose() at soclose+0x3c1
 _fdrop() at _fdrop+0x23
 closef() at closef+0x45
 kern_close() at kern_close+0x163
 syscallenter() at syscallenter+0x23d
 syscall() at syscall+0x4b
 Xfast_syscall() at Copyright (c) 1992-2011 The FreeBSD Project.
 Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
         The Regents of the University of California. All rights =
 reserved.
 FreeBSD is a registered trademark of The FreeBSD Foundation.
 FreeBSD 8.2-RELEASE #3: Fri Feb 25 15:44:51 CET 2011
     root@chassis:/opt/obj/usr/cvsup/8-stable/src/sys/CHASSIS amd64
 Timecounter "i8254" frequency 1193182 Hz quality 0
 CPU: Dual-Core AMD Opteron(tm) Processor 1220 (2814.44-MHz K8-class CPU)
   Origin =3D "AuthenticAMD"  Id =3D 0x40f33  Family =3D f  Model =3D 43  =
 Stepping =3D 3
 

From: Maxim Konovalov <maxim.konovalov@gmail.com>
To: bug-followup@freebsd.org
Cc:  
Subject: kern/151758
Date: Fri, 29 Jul 2011 14:17:27 +0400 (MSD)

 Hello,
 
 can't reproduce the panic with 8.1-STABLE.  Could you please confirm
 you have this problem with the recent version of FreeBSD?
 
 -- 
 Maxim Konovalov

From: John Baldwin <jhb@FreeBSD.org>
To: bug-followup@FreeBSD.org, andrey@shidakov.ru, 
 Konstantin Belousov <kib@freebsd.org>
Cc:  
Subject: Re: kern/151758: [panic] tmux kernel panic, with out root privilegies
Date: Thu, 08 Dec 2011 10:24:56 -0500

 The bug is that during unp_gc(), we pass NULL as the thread to closef() 
 (to disable certain locking stuff, and because the thread performing the 
 gc doesn't "own" orphaned file descriptors in a closed UNIX domain 
 socket).  That resulted in the 'td' argument passed to devfs_close_f() 
 being NULL, so td->td_fpop would fault.  The patch I have (untested) is 
 to force devfs_close_f() to always use curthread instead of trusting the 
 td argument it is given.
 
 Index: /home/jhb/work/freebsd/svn/head/sys/fs/devfs/devfs_vnops.c
 ===================================================================
 --- /home/jhb/work/freebsd/svn/head/sys/fs/devfs/devfs_vnops.c	(revision 
 228311)
 +++ /home/jhb/work/freebsd/svn/head/sys/fs/devfs/devfs_vnops.c	(working 
 copy)
 @@ -602,6 +602,11 @@
   	int error;
   	struct file *fpop;
 
 +	/*
 +	 * NB: td may be NULL if this descriptor is closed due to
 +	 * garbage collection from a closed UNIX domain socket.
 +	 */
 +	td = curthread;
   	fpop = td->td_fpop;
   	td->td_fpop = fp;
   	error = vnops.fo_close(fp, td);
 
 
 -- 
 John Baldwin

From: Kostik Belousov <kostikbel@gmail.com>
To: John Baldwin <jhb@freebsd.org>
Cc: bug-followup@freebsd.org, andrey@shidakov.ru
Subject: Re: kern/151758: [panic] tmux kernel panic, with out root privilegies
Date: Thu, 8 Dec 2011 17:32:36 +0200

 --Z9agJUjEdoIgOYrd
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 Content-Transfer-Encoding: quoted-printable
 
 On Thu, Dec 08, 2011 at 10:24:56AM -0500, John Baldwin wrote:
 > The bug is that during unp_gc(), we pass NULL as the thread to closef()=
 =20
 > (to disable certain locking stuff, and because the thread performing the=
 =20
 > gc doesn't "own" orphaned file descriptors in a closed UNIX domain=20
 > socket).  That resulted in the 'td' argument passed to devfs_close_f()=20
 > being NULL, so td->td_fpop would fault.  The patch I have (untested) is=
 =20
 > to force devfs_close_f() to always use curthread instead of trusting the=
 =20
 > td argument it is given.
 >=20
 > Index: /home/jhb/work/freebsd/svn/head/sys/fs/devfs/devfs_vnops.c
 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 > --- /home/jhb/work/freebsd/svn/head/sys/fs/devfs/devfs_vnops.c	(revision=
 =20
 > 228311)
 > +++ /home/jhb/work/freebsd/svn/head/sys/fs/devfs/devfs_vnops.c	(working=
 =20
 > copy)
 > @@ -602,6 +602,11 @@
 >  	int error;
 >  	struct file *fpop;
 >=20
 > +	/*
 > +	 * NB: td may be NULL if this descriptor is closed due to
 > +	 * garbage collection from a closed UNIX domain socket.
 > +	 */
 > +	td =3D curthread;
 >  	fpop =3D td->td_fpop;
 >  	td->td_fpop =3D fp;
 >  	error =3D vnops.fo_close(fp, td);
 >=20
 I think you need to use either curthread for td_fpop, or create another
 local variable td1 and use it for td_fpop stuff. So that the original
 td is passed to fo_close().
 
 I am curious whether it would cause further NULL pointer dereference
 down the stack.
 
 --Z9agJUjEdoIgOYrd
 Content-Type: application/pgp-signature
 Content-Disposition: inline
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v2.0.18 (FreeBSD)
 
 iEYEARECAAYFAk7g2JQACgkQC3+MBN1Mb4i46gCeJajcv9yq4b8XR6I2MJTkv8v9
 d3kAnjaQt88NwYQ3M9l993qUwzcl0nHv
 =/YUo
 -----END PGP SIGNATURE-----
 
 --Z9agJUjEdoIgOYrd--

From: John Baldwin <jhb@FreeBSD.org>
To: Kostik Belousov <kostikbel@gmail.com>
Cc: bug-followup@freebsd.org, andrey@shidakov.ru
Subject: Re: kern/151758: [panic] tmux kernel panic, with out root privilegies
Date: Thu, 08 Dec 2011 11:02:15 -0500

 On 12/8/11 10:32 AM, Kostik Belousov wrote:
 > On Thu, Dec 08, 2011 at 10:24:56AM -0500, John Baldwin wrote:
 >> The bug is that during unp_gc(), we pass NULL as the thread to closef()
 >> (to disable certain locking stuff, and because the thread performing the
 >> gc doesn't "own" orphaned file descriptors in a closed UNIX domain
 >> socket).  That resulted in the 'td' argument passed to devfs_close_f()
 >> being NULL, so td->td_fpop would fault.  The patch I have (untested) is
 >> to force devfs_close_f() to always use curthread instead of trusting the
 >> td argument it is given.
 >>
 >> Index: /home/jhb/work/freebsd/svn/head/sys/fs/devfs/devfs_vnops.c
 >> ===================================================================
 >> --- /home/jhb/work/freebsd/svn/head/sys/fs/devfs/devfs_vnops.c	(revision
 >> 228311)
 >> +++ /home/jhb/work/freebsd/svn/head/sys/fs/devfs/devfs_vnops.c	(working
 >> copy)
 >> @@ -602,6 +602,11 @@
 >>   	int error;
 >>   	struct file *fpop;
 >>
 >> +	/*
 >> +	 * NB: td may be NULL if this descriptor is closed due to
 >> +	 * garbage collection from a closed UNIX domain socket.
 >> +	 */
 >> +	td = curthread;
 >>   	fpop = td->td_fpop;
 >>   	td->td_fpop = fp;
 >>   	error = vnops.fo_close(fp, td);
 >>
 > I think you need to use either curthread for td_fpop, or create another
 > local variable td1 and use it for td_fpop stuff. So that the original
 > td is passed to fo_close().
 
 Ah, doh.  I thought I had looked to see if td was used elsewhere.  I 
 will update.
 
 > I am curious whether it would cause further NULL pointer dereference
 > down the stack.
 
 Well, I checked all the other fo_close() methods.  All the other ones
 for PASSABLE fd's are safe.  For vnodes the td is passed to vn_close()
 which only uses it to pass it to VOP_CLOSE().  So, we'd have to audit 
 all the filesystems to see if that is safe.
 
 Updated patch:
 
 Index: /home/jhb/work/freebsd/svn/head/sys/fs/devfs/devfs_vnops.c
 ===================================================================
 --- /home/jhb/work/freebsd/svn/head/sys/fs/devfs/devfs_vnops.c	(revision 
 228311)
 +++ /home/jhb/work/freebsd/svn/head/sys/fs/devfs/devfs_vnops.c	(working 
 copy)
 @@ -602,10 +602,14 @@
   	int error;
   	struct file *fpop;
 
 -	fpop = td->td_fpop;
 -	td->td_fpop = fp;
 +	/*
 +	 * NB: td may be NULL if this descriptor is closed due to
 +	 * garbage collection from a closed UNIX domain socket.
 +	 */
 +	fpop = curthread->td_fpop;
 +	curthread->td_fpop = fp;
   	error = vnops.fo_close(fp, td);
 -	td->td_fpop = fpop;
 +	curthread->td_fpop = fpop;
 
   	/*
   	 * The f_cdevpriv cannot be assigned non-NULL value while we
 
 -- 
 John Baldwin
State-Changed-From-To: open->patched 
State-Changed-By: jhb 
State-Changed-When: Fri Dec 9 17:49:43 UTC 2011 
State-Changed-Why:  
Fix committed to HEAD, will MFC in a few weeks when 9.0 freeze is over. 


Responsible-Changed-From-To: freebsd-bugs->jhb 
Responsible-Changed-By: jhb 
Responsible-Changed-When: Fri Dec 9 17:49:43 UTC 2011 
Responsible-Changed-Why:  
Fix committed to HEAD, will MFC in a few weeks when 9.0 freeze is over. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=151758 

From: John Baldwin <jhb@freebsd.org>
To: Kostik Belousov <kostikbel@gmail.com>
Cc: bug-followup@freebsd.org,
 andrey@shidakov.ru
Subject: Re: kern/151758: [panic] tmux kernel panic, with out root privilegies
Date: Fri, 9 Dec 2011 12:42:09 -0500

 On Thursday, December 08, 2011 11:02:15 am John Baldwin wrote:
 > On 12/8/11 10:32 AM, Kostik Belousov wrote:
 > > On Thu, Dec 08, 2011 at 10:24:56AM -0500, John Baldwin wrote:
 > >> The bug is that during unp_gc(), we pass NULL as the thread to closef()
 > >> (to disable certain locking stuff, and because the thread performing the
 > >> gc doesn't "own" orphaned file descriptors in a closed UNIX domain
 > >> socket).  That resulted in the 'td' argument passed to devfs_close_f()
 > >> being NULL, so td->td_fpop would fault.  The patch I have (untested) is
 > >> to force devfs_close_f() to always use curthread instead of trusting the
 > >> td argument it is given.
 > >>
 > >> Index: /home/jhb/work/freebsd/svn/head/sys/fs/devfs/devfs_vnops.c
 > >> ===================================================================
 > >> --- /home/jhb/work/freebsd/svn/head/sys/fs/devfs/devfs_vnops.c	(revision
 > >> 228311)
 > >> +++ /home/jhb/work/freebsd/svn/head/sys/fs/devfs/devfs_vnops.c	(working
 > >> copy)
 > >> @@ -602,6 +602,11 @@
 > >>   	int error;
 > >>   	struct file *fpop;
 > >>
 > >> +	/*
 > >> +	 * NB: td may be NULL if this descriptor is closed due to
 > >> +	 * garbage collection from a closed UNIX domain socket.
 > >> +	 */
 > >> +	td = curthread;
 > >>   	fpop = td->td_fpop;
 > >>   	td->td_fpop = fp;
 > >>   	error = vnops.fo_close(fp, td);
 > >>
 > > I think you need to use either curthread for td_fpop, or create another
 > > local variable td1 and use it for td_fpop stuff. So that the original
 > > td is passed to fo_close().
 > 
 > Ah, doh.  I thought I had looked to see if td was used elsewhere.  I 
 > will update.
 > 
 > > I am curious whether it would cause further NULL pointer dereference
 > > down the stack.
 > 
 > Well, I checked all the other fo_close() methods.  All the other ones
 > for PASSABLE fd's are safe.  For vnodes the td is passed to vn_close()
 > which only uses it to pass it to VOP_CLOSE().  So, we'd have to audit 
 > all the filesystems to see if that is safe.
 > 
 > Updated patch:
 > 
 > Index: /home/jhb/work/freebsd/svn/head/sys/fs/devfs/devfs_vnops.c
 > ===================================================================
 > --- /home/jhb/work/freebsd/svn/head/sys/fs/devfs/devfs_vnops.c	(revision 228311)
 > +++ /home/jhb/work/freebsd/svn/head/sys/fs/devfs/devfs_vnops.c	(working copy)
 > @@ -602,10 +602,14 @@
 >   	int error;
 >   	struct file *fpop;
 > 
 > -	fpop = td->td_fpop;
 > -	td->td_fpop = fp;
 > +	/*
 > +	 * NB: td may be NULL if this descriptor is closed due to
 > +	 * garbage collection from a closed UNIX domain socket.
 > +	 */
 > +	fpop = curthread->td_fpop;
 > +	curthread->td_fpop = fp;
 >   	error = vnops.fo_close(fp, td);
 > -	td->td_fpop = fpop;
 > +	curthread->td_fpop = fpop;
 > 
 >   	/*
 >   	 * The f_cdevpriv cannot be assigned non-NULL value while we
 
 FYI, I wrote a simple regression test which reproduced the panic below.
 The patch fixes the panic.
 
 /*-
  * Test program to provoke the panic in PR 151758 by orphaning an open
  * file descriptor for a cdev on a UNIX domain socket.
  */
 
 #include <sys/types.h>
 #include <sys/socket.h>
 #include <err.h>
 #include <fcntl.h>
 #include <string.h>
 #include <unistd.h>
 
 int
 main(int ac, char **av)
 {
 	struct msghdr msg;
 	struct cmsghdr *cmsg;
 	char control[256];
 	int sock[2], fd, *fdp;
 
 	fd = open("/dev/null", O_RDONLY);
 	if (fd < 0)
 		err(1, "open(\"/dev/null\")");
 	if (socketpair(AF_LOCAL, SOCK_DGRAM, 0, sock) < 0)
 		err(1, "socketpair(AF_LOCAL, SOCK_DGRAM)");
 
 	cmsg = (struct cmsghdr *)control;
 	cmsg->cmsg_level = SOL_SOCKET;
 	cmsg->cmsg_type = SCM_RIGHTS;
 	fdp = (int *)CMSG_DATA(cmsg);
 	fdp[0] = fd;
 	cmsg->cmsg_len = (char *)(&fdp[1]) - control;
 	memset(&msg, 0, sizeof(msg));
 	msg.msg_control = control;
 	msg.msg_controllen = cmsg->cmsg_len;
 	if (sendmsg(sock[0], &msg, 0) < 0)
 		err(1, "sendmsg");
 	close(fd);
 	close(sock[0]);
 	close(sock[1]);
 	return (0);
 }
 
 -- 
 John Baldwin

From: dfilter@FreeBSD.ORG (dfilter service)
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/151758: commit references a PR
Date: Fri,  9 Dec 2011 17:49:49 +0000 (UTC)

 Author: jhb
 Date: Fri Dec  9 17:49:34 2011
 New Revision: 228361
 URL: http://svn.freebsd.org/changeset/base/228361
 
 Log:
   Explicitly use curthread while manipulating td_fpop during last close
   of a devfs file descriptor in devfs_close_f().  The passed in td argument
   may be NULL if the close was invoked by garbage collection of open
   file descriptors in pending control messages in the socket buffer of a
   UNIX domain socket after it was closed.
   
   PR:		kern/151758
   Submitted by:	Andrey Shidakov  andrey shidakov ru
   Submitted by:	Ruben van Staveren  ruben verweg com
   Reviewed by:	kib
   MFC after:	2 weeks
 
 Modified:
   head/sys/fs/devfs/devfs_vnops.c
 
 Modified: head/sys/fs/devfs/devfs_vnops.c
 ==============================================================================
 --- head/sys/fs/devfs/devfs_vnops.c	Fri Dec  9 17:19:41 2011	(r228360)
 +++ head/sys/fs/devfs/devfs_vnops.c	Fri Dec  9 17:49:34 2011	(r228361)
 @@ -602,10 +602,14 @@ devfs_close_f(struct file *fp, struct th
  	int error;
  	struct file *fpop;
  
 -	fpop = td->td_fpop;
 -	td->td_fpop = fp;
 +	/*
 +	 * NB: td may be NULL if this descriptor is closed due to
 +	 * garbage collection from a closed UNIX domain socket.
 +	 */
 +	fpop = curthread->td_fpop;
 +	curthread->td_fpop = fp;
  	error = vnops.fo_close(fp, td);
 -	td->td_fpop = fpop;
 +	curthread->td_fpop = fpop;
  
  	/*
  	 * The f_cdevpriv cannot be assigned non-NULL value while we
 _______________________________________________
 svn-src-all@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/svn-src-all
 To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org"
 
State-Changed-From-To: patched->closed 
State-Changed-By: jhb 
State-Changed-When: Thu Jan 5 19:36:47 UTC 2012 
State-Changed-Why:  
Fix merged to 8 and 9. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=151758 
>Unformatted:
