Re: kern/151758: [panic] tmux kernel panic,

The following reply was made to PR kern/151758; it has been noted by GNATS.

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--
_______________________________________________
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscribe@freebsd.org"