From marcolz@synth.ilse.net  Wed Jul 13 09:26:14 2005
Return-Path: <marcolz@synth.ilse.net>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id BCAD716A41C
	for <FreeBSD-gnats-submit@freebsd.org>; Wed, 13 Jul 2005 09:26:14 +0000 (GMT)
	(envelope-from marcolz@synth.ilse.net)
Received: from synth.ilse.net (pip0-7.ilse.nl [62.69.162.177])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 45F1843D48
	for <FreeBSD-gnats-submit@freebsd.org>; Wed, 13 Jul 2005 09:26:13 +0000 (GMT)
	(envelope-from marcolz@synth.ilse.net)
Received: from synth.ilse.net (localhost.ilse.nl [127.0.0.1])
	by synth.ilse.net (8.13.3/8.13.1) with ESMTP id j6D9QC4w001063
	for <FreeBSD-gnats-submit@freebsd.org>; Wed, 13 Jul 2005 11:26:12 +0200 (CEST)
	(envelope-from marcolz@synth.ilse.net)
Received: (from marcolz@localhost)
	by synth.ilse.net (8.13.3/8.13.1/Submit) id j6D9QB6T001062;
	Wed, 13 Jul 2005 11:26:11 +0200 (CEST)
	(envelope-from marcolz)
Message-Id: <200507130926.j6D9QB6T001062@synth.ilse.net>
Date: Wed, 13 Jul 2005 11:26:11 +0200 (CEST)
From: Marc Olzheim <marcolz@stack.nl>
Reply-To: Marc Olzheim <marcolz@stack.nl>
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: Fatal trap 12 cloning a pty
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         83375
>Category:       kern
>Synopsis:       [lor] Fatal trap 12 cloning a pty
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    mbr
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Jul 13 09:30:13 GMT 2005
>Closed-Date:    Fri Feb 29 00:57:10 UTC 2008
>Last-Modified:  Sun Feb 15 19:08:19 UTC 2009
>Originator:     Marc Olzheim
>Release:        FreeBSD 5.4-STABLE i386 and 6.0-CURRENT i386
>Organization:
ilse media
>Environment:
System: FreeBSD synth.ilse.net 5.4-STABLE FreeBSD 5.4-STABLE #2: Fri Jul 1 17:08:52 CEST 2005 root@rave.ilse.net:/usr/obj/usr/src/sys/SE3INVAR i386

and

FreeBSD office-install1.ilse.net 6.0-CURRENT FreeBSD 6.0-CURRENT #27: Mon Jul 11 13:03:37 CEST 2005     root@office-install1.ilse.net:/usr/obj/usr/src/sys/CRASH  i386

	Dual Xeon machine, RELENG_5 SMP kernel with INVARIANTS enabled
	to avert this crash for some time.

	and

	Dual Celeron 6.0-CURRENT SMP with practically GENERIC kernel.

	Haven't found a non-SMP machine to test on yet.

>Description:
	Opening a new tty by for instance screen often goes horribly
	wrong. On RELENG_5, it crashes in ptsopen(), on (6-)CURRENT, it
	crashes in the devfs cloning and cleanup routines (each time a
	different location).
>How-To-Repeat:
	Run this:

	crashpts.sh:
-----8<----------8<----------8<----------8<-----
#!/bin/sh

count=0
while true
do
	screen -d -m -c "${PWD}/.screenrc.crashpts" &
	count=$(($count+1))
	if [ $(($count%30)) = 0 ]
	then
		killall screen
		sleep 2
		killall -9 screen
	fi
done
-----8<----------8<----------8<----------8<-----

	screenrc.crashpts:
-----8<----------8<----------8<----------8<-----
screen
screen
screen
screen
screen
screen
screen
screen
screen
screen
-----8<----------8<----------8<----------8<-----
>Fix:
>Release-Note:
>Audit-Trail:

From: Marc Olzheim <marcolz@stack.nl>
To: FreeBSD-gnats-submit@FreeBSD.org, freebsd-bugs@FreeBSD.org
Cc: Marc Olzheim <marcolz@stack.nl>
Subject: Re: kern/83375: Fatal trap 12 cloning a pty
Date: Wed, 13 Jul 2005 22:04:05 +0200

 On Wed, Jul 13, 2005 at 09:30:13AM +0000, FreeBSD-gnats-submit@FreeBSD.org wrote:
 Here's the FreeBSD 5.4-STABLE trace:
 
 Fatal trap 12: page fault while in kernel mode
 cpuid = 0; apic id = 00
 fault virtual address   = 0x3b271cd8
 fault code              = supervisor read, page not present
 instruction pointer     = 0x8:0xc0557bd0
 stack pointer           = 0x10:0xebd9a9ec
 frame pointer           = 0x10:0xebd9a9f8
 code segment            = base 0x0, limit 0xfffff, type 0x1b
                         = DPL 0, pres 1, def32 1, gran 1
 processor eflags        = interrupt enabled, resume, IOPL = 0
 current process         = 8993 (screen)
 [thread pid 8993 tid 100342 ]
 Stopped at      0xc0557bd0 = ptsopen+0xb8:      movl    0xc0701960 = linesw(,%eax,4),%eax
 db> tr
 Tracing pid 8993 tid 100342 td 0xc64cc300
 ptsopen(c7e8ea00,3,2000,c64cc300,ebd9aa60) at 0xc0557bd0 = ptsopen+0xb8
 spec_open(ebd9aa60,ebd9ab1c,c0581339,ebd9aa60,180) at 0xc04f292c = spec_open+0x28c
 spec_vnoperate(ebd9aa60) at 0xc04f269b = spec_vnoperate+0x13
 vn_open_cred(ebd9abd4,ebd9acd4,0,c7d0d600,7) at 0xc0581339 = vn_open_cred+0x431
 vn_open(ebd9abd4,ebd9acd4,0,7,c0724b20) at 0xc0580f06 = vn_open+0x1e
 kern_open(c64cc300,bfbfc910,0,3,0) at 0xc057b0b4 = kern_open+0xcc
 open(c64cc300,ebd9ad04,3,2a,282) at 0xc057afe4 = open+0x18
 syscall(2f,281e002f,bfbf002f,6,bfbfc910) at 0xc06803eb = syscall+0x227
 Xint0x80_syscall() at 0xc066fcef = Xint0x80_syscall+0x1f
 --- syscall (5, FreeBSD ELF32, open), eip = 0x2816c7bb, esp = 0xbfbfc8dc, ebp = 0xbfbfc938 ---
 db> 

From: Marc Olzheim <marcolz@stack.nl>
To: FreeBSD-gnats-submit@FreeBSD.org, freebsd-bugs@FreeBSD.org
Cc: Marc Olzheim <marcolz@stack.nl>
Subject: Re: kern/83375: Fatal trap 12 cloning a pty
Date: Thu, 14 Jul 2005 14:55:52 +0200

 And another FreeBSD 5.4-STABLE trace, now the 'close()' variant:
 
 Fatal trap 12: page fault while in kernel mode
 cpuid = 2; apic id = 06
 fault virtual address   = 0x3b26cff8
 fault code              = supervisor read, page not present
 instruction pointer     = 0x8:0xc0554a9c
 stack pointer           = 0x10:0xebd4bb48
 frame pointer           = 0x10:0xebd4bb4c
 code segment            = base 0x0, limit 0xfffff, type 0x1b
                         = DPL 0, pres 1, def32 1, gran 1
 processor eflags        = interrupt enabled, resume, IOPL = 0
 current process         = 54879 (screen)
 [thread pid 54879 tid 100324 ]
 Stopped at      0xc0554a9c = ptcclose+0x10:     movl    0xc06fcc80 = linesw(,%eax,4),%eax
 db> tr
 Tracing pid 54879 tid 100324 td 0xc6409600
 ptcclose(c6814a00,7,2000,c6409600,c06fcf40) at 0xc0554a9c = ptcclose+0x10
 spec_close(ebd4bb90,ebd4bbb8,c057e18a,ebd4bb90,c0716660) at 0xc04f0357 = spec_close+0x277
 spec_vnoperate(ebd4bb90) at 0xc04ef49f = spec_vnoperate+0x13
 vn_close(c67bc318,7,c7434900,c6409600,c6409600) at 0xc057e18a = vn_close+0x5a
 vn_closefile(c6ad0d48,c6409600) at 0xc057f05e = vn_closefile+0xaa
 fdrop_locked(c6ad0d48,c6409600,c5628a54,0,c06b951b) at 0xc050b394 = fdrop_locked+0x88
 fdrop(c6ad0d48,c6409600,ffffffdf,80a767c,0) at 0xc050b304 = fdrop+0x24
 closef(c6ad0d48,c6409600,0,c067d1f8,5) at 0xc0509e0f = closef+0x313
 close(c6409600,ebd4bd04,1,1,246) at 0xc050792f = close+0x1a3
 syscall(bfbf002f,2f,bfbf002f,80a5000,80a5000) at 0xc067d05b = syscall+0x227
 Xint0x80_syscall() at 0xc066c95f = Xint0x80_syscall+0x1f
 --- syscall (6, FreeBSD ELF32, close), eip = 0x2816c79b, esp = 0xbfbfd23c, ebp = 0xbfbfd258 ---
 db>

From: Sven Berkvens-Matthijsse <sven@ilse.net>
To: bug-followup@freebsd.org
Cc: marcolz@stack.nl
Subject: Re: kern/83375: Fatal trap 12 cloning a pty
Date: Fri, 15 Jul 2005 09:16:53 +0200

 Following up on this: the t_line member of the struct tty that the
 ttyld_modem() macro is looking at (which should be an integer from 0
 upto but not including nlinesw, which is 9 on this system), is
 actually an address of some sort. The t_line integer's value is
 0xc5f0cd48. I have no idea how this could ever get there, I can't find
 anything in the kernel code that could cause this, at least, not by
 setting t_line itself. Perhaps the tty structure is corrupted by a
 function that is not supposed to do anything with t_line at all.
 
 -- 
 Sven

From: Marc Olzheim <marcolz@stack.nl>
To: FreeBSD-gnats-submit@FreeBSD.org, freebsd-bugs@FreeBSD.org
Cc: Marc Olzheim <marcolz@stack.nl>
Subject: Re: kern/83375: Fatal trap 12 cloning a pty
Date: Fri, 15 Jul 2005 12:04:39 +0200

 Non-SMP 7-CURRENT suffers from this as well...

From: Marc Olzheim <marcolz@stack.nl>
To: FreeBSD-gnats-submit@FreeBSD.org, freebsd-bugs@FreeBSD.org
Cc: Marc Olzheim <marcolz@stack.nl>
Subject: Re: kern/83375: Fatal trap 12 cloning a pty
Date: Fri, 15 Jul 2005 15:43:32 +0200

 Today's non-SMP 7-CURRENT backtrace from kgdb:
 
 #25 0xc0500612 in dev_ref (dev=0x0) at /usr/src/sys/kern/kern_conf.c:75
 #26 0xc057063a in ctty_clone (arg=0x0, name=0x0, namelen=3, dev=0xd073d86c)
     at /usr/src/sys/kern/tty_tty.c:68
 #27 0xc04cafcb in devfs_lookupx (ap=0x0)
     at /usr/src/sys/fs/devfs/devfs_vnops.c:708
 #28 0xc04cb224 in devfs_lookup (ap=0xd073d998)
     at /usr/src/sys/fs/devfs/devfs_vnops.c:764
 #29 0xc0713bf4 in VOP_LOOKUP_APV (vop=0xc076e5c0, a=0xd073d998)
     at vnode_if.c:99
 #30 0xc058f438 in lookup (ndp=0xd073dbc4) at vnode_if.h:56
 #31 0xc058ece8 in namei (ndp=0xd073dbc4) at /usr/src/sys/kern/vfs_lookup.c:201
 #32 0xc05a39f8 in vn_open_cred (ndp=0xd073dbc4, flagp=0xd073dcc4, cmode=0, 
     cred=0xc1d35000, fdidx=3) at /usr/src/sys/kern/vfs_vnops.c:182
 #33 0xc05a3723 in vn_open (ndp=0x0, flagp=0x0, cmode=0, fdidx=0)
     at /usr/src/sys/kern/vfs_vnops.c:91
 #34 0xc059b8e8 in kern_open (td=0xc1d12900, path=0x0, pathseg=UIO_USERSPACE, 
     flags=32771, mode=0) at /usr/src/sys/kern/vfs_syscalls.c:979
 #35 0xc059b7d6 in open (td=0x0, uap=0xd073dd04)
     at /usr/src/sys/kern/vfs_syscalls.c:945
 #36 0xc06fe900 in syscall (frame=
       {tf_fs = 59, tf_es = 59, tf_ds = 59, tf_edi = 672136768, tf_esi = 673366572, tf_ebp = -1077942024, tf_isp = -797713052, tf_ebx = 672114944, tf_edx = -1, tf_ecx = 6, tf_eax = 5, tf_trapno = 12, tf_err = 2, tf_eip = 672798543, tf_cs = 51, tf_eflags = 582, tf_esp = -1077942068, tf_ss = 59})
     at /usr/src/sys/i386/i386/trap.c:985
 #37 0xc06ee3df in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:198

From: Marc Olzheim <marcolz@stack.nl>
To: FreeBSD-gnats-submit@FreeBSD.org, freebsd-bugs@FreeBSD.org
Cc: Marc Olzheim <marcolz@stack.nl>
Subject: Re: kern/83375: Fatal trap 12 cloning a pty
Date: Tue, 19 Jul 2005 11:50:01 +0200

 5.4-RELEASE-p4 broke down to me as well:
 
 Fatal trap 12: page fault while in kernel mode
 cpuid = 0; apic id = 00
 fault virtual address   = 0x1c
 fault code              = supervisor write, page not present
 instruction pointer     = 0x8:0xc0512b03
 stack pointer           = 0x10:0xebaeb9bc
 frame pointer           = 0x10:0xebaeb9c8
 code segment            = base 0x0, limit 0xfffff, type 0x1b
                         = DPL 0, pres 1, def32 1, gran 1
 processor eflags        = interrupt enabled, resume, IOPL = 0
 current process         = 5514 (screen)
 [thread pid 5514 tid 100166 ]
 Stopped at      0xc0512b03 = knote+0x27:        lock cmpxchgl   %ecx,0x1c(%edx)
 db> trace
 Tracing pid 5514 tid 100166 td 0xc5cb3900
 knote(c5e96c80,0,0,c5e96c10,c5e96c00) at 0xc0512b03 = knote+0x27
 ttwakeup(c5e96c00,c5e96c00,c5e96c00,c65d7200,ebaeba14) at 0xc055c465 = ttwakeup+0x65
 ttymodem(c5e96c00,1) at 0xc055b0c8 = ttymodem+0x170
 ptcopen(c65d7200,3,2000,c5cb3900,c0710800) at 0xc055edb3 = ptcopen+0x63
 spec_open(ebaeba80,ebaebb3c,c058cd35,ebaeba80,180) at 0xc04f19ce = spec_open+0x2b6
 spec_vnoperate(ebaeba80) at 0xc04f1713 = spec_vnoperate+0x13
 vn_open_cred(ebaebbe4,ebaebce4,0,c6e64400,a) at 0xc058cd35 = vn_open_cred+0x419
 vn_open(ebaebbe4,ebaebce4,0,a,0) at 0xc058c91a = vn_open+0x1e
 kern_open(c5cb3900,bfbfc6a0,0,3,0) at 0xc05867c7 = kern_open+0xeb
 open(c5cb3900,ebaebd14,3,1,292) at 0xc05866d8 = open+0x18
 syscall(bfbf002f,2f,bfbf002f,ffffffff,28104c2d) at 0xc0699677 = syscall+0x2b3
 Xint0x80_syscall() at 0xc06885ef = Xint0x80_syscall+0x1f
 --- syscall (5, FreeBSD ELF32, open), eip = 0x2816c7bb, esp = 0xbfbfc66c, ebp = 0xbfbfc6c8 ---
 db> show reg
 cs                 0x8
 ds                0x10
 es           0x1000010
 fs          0xebae0018
 ss                0x10
 eax                0x4
 ecx         0xc5cb3900
 edx                  0
 ebx         0xc5e96c00
 esp         0xebaeb9bc
 ebp         0xebaeb9c8
 esi         0xc65d7200
 edi         0xc65ce630
 eip         0xc0512b03  knote+0x27
 efl            0x10246
 dr0                  0
 dr1                  0
 dr2                  0
 dr3                  0
 dr4         0xffff0ff0
 dr5              0x400
 dr6         0xffff0ff0
 dr7              0x400
 0xc0512b03 = knote+0x27:        lock cmpxchgl   %ecx,0x1c(%edx)
 db>
Responsible-Changed-From-To: freebsd-bugs->phk 
Responsible-Changed-By: rwatson 
Responsible-Changed-When: Tue Jul 19 15:11:16 GMT 2005 
Responsible-Changed-Why:  
Assign tty/pty/cloning related bug to phk, since this is his area. 


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

From: Marc Olzheim <marcolz@stack.nl>
To: FreeBSD-gnats-submit@FreeBSD.org, freebsd-bugs@FreeBSD.org
Cc:  
Subject: Re: kern/83375: Fatal trap 12 cloning a pty
Date: Wed, 21 Sep 2005 16:57:52 +0200

 Is there any progress on this ? Could someone give me pointers to where
 the problem might be ?
 
 I already had to downgrade servers to FreeBSD 4.11 :-(
 
 Marc

From: Marc Olzheim <marcolz@stack.nl>
To: bug-followup@freebsd.org, phk@FreeBSD.org
Cc: Marc Olzheim <marcolz@stack.nl>, bzeeb+freebsd+lor@zabbadoz.net
Subject: Re: kern/83375: Fatal trap 12 cloning a pty
Date: Thu, 22 Sep 2005 17:53:41 +0200

 --wzJLGUyc3ArbnUjN
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 
 The traces on 6.0-BETA5 are a bit different then before btw AND it
 produced a LOR right before cragshing now.
 
 On the comconsole:
 
 login: lock order reversal
  1st 0xc07586c0 cdev (cdev) @ /usr/src/sys/kern/kern_conf.c:79
  2nd 0xc579f68c process lock (process lock) @ /usr/src/sys/i386/i386/trap.c:724
 KDB: stack backtrace:
 kdb_backtrace(0,ffffffff,c076b068,c076b540,c07320a4) at 0xc054f309 = kdb_backtrace+0x29
 witness_checkorder(c579f68c,9,c0710496,2d4) at 0xc055917c = witness_checkorder+0x564
 _mtx_lock_flags(c579f68c,0,c0710496,2d4,c5734180) at 0xc052f7bf = _mtx_lock_flags+0x5b
 trap_pfault(e99dc7e4,0,30) at 0xc06aedda = trap_pfault+0x92
 trap(c0750008,c0760028,c0750028,c59c3000,c573a400) at 0xc06aeb19 = trap+0x319
 calltrap() at 0xc069d04a = calltrap+0x5
 --- trap 0xc, eip = 0xc0513625, esp = 0xe99dc824, ebp = 0xe99dc848 ---
 dev_ref(0,c56bcd00,e99dc944,c04f0d92,0) at 0xc0513625 = dev_ref+0x2d
 ctty_clone(0,c64ae600,e99dc934,3,e99dc8a4,c573a40c,0,c06e95e7,227) at 0xc056c597 = ctty_clone+0x77
 devfs_lookupx(e99dc9c4,c57f2318,1,0,c5734180) at 0xc04f0d92 = devfs_lookupx+0x342
 devfs_lookup(e99dc9c4,c59c3000,0,e99dc9e0,c0584b2e) at 0xc04f0fa2 = devfs_lookup+0x2e
 VOP_LOOKUP_APV(c072aa40,e99dc9c4) at 0xc06bdf97 = VOP_LOOKUP_APV+0x87
 lookup(e99dcbcc,c0559e90,0,c5734180,c078b4c0) at 0xc0584b2e = lookup+0x3d6
 namei(e99dcbcc,c06f1ebe,267,c5734180,e99dca68) at 0xc05844f6 = namei+0x37e
 vn_open_cred(e99dcbcc,e99dcccc,438,c64ae600,3) at 0xc0594def = vn_open_cred+0x277
 vn_open(e99dcbcc,e99dcccc,438,3,0) at 0xc0594b76 = vn_open+0x1e
 kern_open(c5734180,280e4bca,0,8003,bfbfe638) at 0xc058e56e = kern_open+0xb6
 open(c5734180,e99dcd04,3,1c,292) at 0xc058e482 = open+0x1a
 syscall(3b,3b,bfbf003b,280f4620,280f4620) at 0xc06af457 = syscall+0x22f
 Xint0x80_syscall() at 0xc069d09f = Xint0x80_syscall+0x1f
 --- syscall (5, FreeBSD ELF32, open), eip = 0x281977bb, esp = 0xbfbfe5fc, ebp = 0xbfbfe638 ---
 
 
 Fatal trap 12: page fault while in kernel mode
 cpuid = 2; apic id = 06
 fault virtual address   = 0x30
 fault code              = supervisor write, page not present
 instruction pointer     = 0x20:0xc0513625
 stack pointer           = 0x28:0xe99dc824
 frame pointer           = 0x28:0xe99dc848
 code segment            = base 0x0, limit 0xfffff, type 0x1b
                         = DPL 0, pres 1, def32 1, gran 1
 processor eflags        = interrupt enabled, resume, IOPL = 0
 current process         = 3214 (zsh)
 trap number             = 12
 panic: page fault
 cpuid = 2
 KDB: stack backtrace:
 kdb_backtrace(100,c5734180,28,e99dc7e4,c) at 0xc054f309 = kdb_backtrace+0x29
 panic(c06d93ab,c07102b4,0,fffff,c579f69b) at 0xc05376ec = panic+0x114
 trap_fatal(e99dc7e4,30,c5734180,c64cea8c,0) at 0xc06af1a2 = trap_fatal+0x2ca
 trap_pfault(e99dc7e4,0,30) at 0xc06aeeaf = trap_pfault+0x167
 trap(c0750008,c0760028,c0750028,c59c3000,c573a400) at 0xc06aeb19 = trap+0x319
 calltrap() at 0xc069d04a = calltrap+0x5
 --- trap 0xc, eip = 0xc0513625, esp = 0xe99dc824, ebp = 0xe99dc848 ---
 dev_ref(0,c56bcd00,e99dc944,c04f0d92,0) at 0xc0513625 = dev_ref+0x2d
 ctty_clone(0,c64ae600,e99dc934,3,e99dc8a4,c573a40c,0,c06e95e7,227) at 0xc056c597 = ctty_clone+0x77
 devfs_lookupx(e99dc9c4,c57f2318,1,0,c5734180) at 0xc04f0d92 = devfs_lookupx+0x342
 devfs_lookup(e99dc9c4,c59c3000,0,e99dc9e0,c0584b2e) at 0xc04f0fa2 = devfs_lookup+0x2e
 VOP_LOOKUP_APV(c072aa40,e99dc9c4) at 0xc06bdf97 = VOP_LOOKUP_APV+0x87
 lookup(e99dcbcc,c0559e90,0,c5734180,c078b4c0) at 0xc0584b2e = lookup+0x3d6
 namei(e99dcbcc,c06f1ebe,267,c5734180,e99dca68) at 0xc05844f6 = namei+0x37e
 vn_open_cred(e99dcbcc,e99dcccc,438,c64ae600,3) at 0xc0594def = vn_open_cred+0x277
 vn_open(e99dcbcc,e99dcccc,438,3,0) at 0xc0594b76 = vn_open+0x1e
 kern_open(c5734180,280e4bca,0,8003,bfbfe638) at 0xc058e56e = kern_open+0xb6
 open(c5734180,e99dcd04,3,1c,292) at 0xc058e482 = open+0x1a
 syscall(3b,3b,bfbf003b,280f4620,280f4620) at 0xc06af457 = syscall+0x22f
 Xint0x80_syscall() at 0xc069d09f = Xint0x80_syscall+0x1f
 --- syscall (5, FreeBSD ELF32, open), eip = 0x281977bb, esp = 0xbfbfe5fc, ebp = 0xbfbfe638 ---
 Uptime: 11m26s
 Dumping 3967 MB (3 chunks)
   chunk 0: 1MB (159 pages) ... ok
   chunk 1: 3966MB (1015280 pages) 3950 ...
 
 Marc
 
 --wzJLGUyc3ArbnUjN
 Content-Type: application/pgp-signature
 Content-Disposition: inline
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.2 (FreeBSD)
 
 iD8DBQFDMtOFezjnobFOgrERAr8YAJ4zhVpvUVKStyGxMKUyeSlZ3LLDogCgkEde
 WYwt0Fp1otsUZicYV36BCkk=
 =3hzQ
 -----END PGP SIGNATURE-----
 
 --wzJLGUyc3ArbnUjN--

From: "Bjoern A. Zeeb" <bzeeb+freebsd+lor@zabbadoz.net>
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/83375: Fatal trap 12 cloning a pty
Date: Thu, 22 Sep 2005 17:43:05 +0000 (UTC)

 For the archies. I add the this with LOR ID 164 though it might be
 bogus becaus of the trap...
 http://sources.zabbadoz.net/freebsd/lor.html#164

From: Robert Watson <rwatson@FreeBSD.org>
To: Marc Olzheim <marcolz@stack.nl>
Cc: FreeBSD-gnats-submit@FreeBSD.org, freebsd-bugs@FreeBSD.org
Subject: Re: kern/83375: Fatal trap 12 cloning a pty
Date: Mon, 26 Sep 2005 10:08:53 +0100 (BST)

 On Wed, 21 Sep 2005, Marc Olzheim wrote:
 
 > Is there any progress on this ? Could someone give me pointers to where 
 > the problem might be ?
 >
 > I already had to downgrade servers to FreeBSD 4.11 :-(
 
 Are you able to confirm whether this problem has gone away or been fixed 
 in FreeBSD 6.0-BETAx?
 
 Robert N M Watson

From: Marc Olzheim <marcolz@stack.nl>
To: Robert Watson <rwatson@FreeBSD.org>
Cc: Marc Olzheim <marcolz@stack.nl>,
	FreeBSD-gnats-submit@FreeBSD.org, freebsd-bugs@FreeBSD.org
Subject: Re: kern/83375: Fatal trap 12 cloning a pty
Date: Mon, 26 Sep 2005 16:08:23 +0200

 --zhXaljGHf11kAtnf
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 Content-Transfer-Encoding: quoted-printable
 
 On Mon, Sep 26, 2005 at 10:08:53AM +0100, Robert Watson wrote:
 >=20
 > On Wed, 21 Sep 2005, Marc Olzheim wrote:
 >=20
 > >Is there any progress on this ? Could someone give me pointers to where=
 =20
 > >the problem might be ?
 > >
 > >I already had to downgrade servers to FreeBSD 4.11 :-(
 >=20
 > Are you able to confirm whether this problem has gone away or been fixed=
 =20
 > in FreeBSD 6.0-BETAx?
 
 It's still present in each and every recent version except for 4.x.
 
 Marc
 
 --zhXaljGHf11kAtnf
 Content-Type: application/pgp-signature
 Content-Disposition: inline
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.2 (FreeBSD)
 
 iD8DBQFDOADXezjnobFOgrERAlg9AJ9e70zU8dQ5bcke2xDIMni6sKQvUACfVAdf
 +Mh+YBbXASBQ2ke1VEGs0so=
 =LT6u
 -----END PGP SIGNATURE-----
 
 --zhXaljGHf11kAtnf--

From: Robert Watson <rwatson@FreeBSD.org>
To: Marc Olzheim <marcolz@stack.nl>
Cc: FreeBSD-gnats-submit@FreeBSD.org, freebsd-bugs@FreeBSD.org
Subject: Re: kern/83375: Fatal trap 12 cloning a pty
Date: Mon, 26 Sep 2005 15:12:27 +0100 (BST)

 On Mon, 26 Sep 2005, Marc Olzheim wrote:
 
 > On Mon, Sep 26, 2005 at 10:08:53AM +0100, Robert Watson wrote:
 >>
 >> On Wed, 21 Sep 2005, Marc Olzheim wrote:
 >>
 >>> Is there any progress on this ? Could someone give me pointers to where
 >>> the problem might be ?
 >>>
 >>> I already had to downgrade servers to FreeBSD 4.11 :-(
 >>
 >> Are you able to confirm whether this problem has gone away or been fixed
 >> in FreeBSD 6.0-BETAx?
 >
 > It's still present in each and every recent version except for 4.x.
 
 Crumbs.
 
 I need to spend some more time on some fifo bugs, and will then try to get 
 back investigate the pty issue.  phk is signed up to do general tty work 
 this fall, but probably not on a time schedule that will help with 5.5.
 
 Thanks for your persistence!
 
 Robert N M Watson

From: Nate Eldredge <nge@cs.hmc.edu>
To: bug-followup@FreeBSD.org, marcolz@stack.nl
Cc: peter@holm.cc, freebsd-current@freebsd.org, rwatson@freebsd.org,
	Philippe.Pegon@crc.u-strasbg.fr
Subject: Re: kern/83375: Fatal trap 12 cloning a pty (was: show stopper for
 FreeBSD 6)
Date: Tue, 1 Nov 2005 18:59:08 -0800 (PST)

 Okay, well I have made some progress here.  The problem, at least on 
 7.0-CURRENT, occurs when you revoke() somebody's controlling tty, and then 
 they try to clone it by opening /dev/tty.  revoke() will set the vnode's 
 type to VBAD and ->v_rdev to NULL.  However ctty_clone() assumes that if 
 the P_CONTROLT flag is set and p_session->s_ttyvp is non-null then 
 s_ttyvp->v_rdev is non-null as well, and it passes it to dev_ref which 
 dereferences the pointer.
 
 One way to fix this is to have ctty_clone check for v_type == VBAD and/or 
 v_rdev == NULL, and treat it like the case of s_ttyvp == NULL (give them 
 the dummy /dev/ctty instead).  Does that seem reasonable?  I am not very 
 familiar with the kernel, just trying to learn through fixing bugs.  When 
 I do that, the screen testcase works until the machine runs out of memory 
 :)
 
 The dumps posted from 5.x look very different and this may be a separate 
 bug.  Unfortunately I don't have a 5.x test box.
 
 Here is a simpler test case.  I use /dev/ttyv9 as the terminal device, so 
 you have to be root to run it, but it should also work with a pty.  So a 
 regular user could exploit this.
 
 ------------------------snip---------------------
 #include <stdlib.h>
 #include <stdio.h>
 #include <unistd.h>
 #include <fcntl.h>
 #include <sys/ioctl.h>
 #include <sys/wait.h>
 #include <string.h>
 
 #define TTY "/dev/ttyv9" /* should be totally unused */
 #define CTTY "/dev/tty"
 
 int main(void) {
    int ttyfd;
    pid_t pid;
    /* Get rid of my ctty. */
    printf("Parent starting: pid %d\n", getpid());
    pid = fork();
    if (pid < 0) {
      perror("fork");
      exit(1);
    } else if (pid > 0) {
      int status;
      /* parent */
      waitpid(pid, &status, 0);
      exit(0);
    }
    /* child */
    printf("Child: pid %d\n", getpid());
 
    if (setsid() < 0) {
      perror("setsid");
      exit(1);
    }
 
    ttyfd = open(TTY, O_RDWR);
    if (ttyfd < 0) {
      perror(TTY);
      exit(1);
    }
    if (ioctl(ttyfd, TIOCSCTTY) < 0) {
      perror("ioctl(TIOCSCTTY)");
      exit(1);
    }
 
    if (revoke(TTY) < 0) {
      perror("revoke");
      exit(1);
    }
 
    if (open(CTTY, O_RDWR) < 0) {
      perror(CTTY);
      exit(1);
    }
    return 0;
 }
 -----------------------------snip-------------------
 
 -- 
 Nate Eldredge
 nge@cs.hmc.edu

From: Nate Eldredge <nge@cs.hmc.edu>
To: bug-followup@FreeBSD.org, marcolz@stack.nl
Cc: Philippe.Pegon@crc.u-strasbg.fr
Subject: Re: kern/83375: Fatal trap 12 cloning a pty [PATCH]
Date: Sat, 17 Dec 2005 00:01:22 -0800 (PST)

 Well, I finally got back to this.  As mentioned, the problem is when you 
 open /dev/tty after your controlling terminal has been revoked.  I found 
 that OpenBSD and NetBSD both fail the open call in that case, so I figure 
 we should do so as well.  This can be done in ctty_clone by returning with 
 *dev==NULL.  Admittedly this causes open to return ENOENT, instead of 
 ENXIO as on the other BSDs, but this way requires the least touching of 
 code.
 
 Here is my patch, versus CURRENT.  I wasn't sure which is the more certain 
 indication of a revoked terminal: s_ttyvp->v_type == VBAD or ->v_rdev == 
 NULL.  So here we check both.  The latter check is somewhat more foolproof 
 since we will certainly crash if we continue with ->v_rdev NULL.
 
 Since this is a local DoS on all platforms it should probably be fixed 
 sooner than later, and also MFC'ed, IMHO.  (I am not a committer.)
 
 Again, this PR seems like it may involve two separate bugs.  The one 
 reported on July 13 in 5.4-STABLE looks like something else and this patch 
 probably does not fix it.  The bug which it does fix is the one reported 
 July 15.
 
 Index: sys/kern/tty_tty.c
 ===================================================================
 RCS file: /medium/cvs/FreeBSD/src/sys/kern/tty_tty.c,v
 retrieving revision 1.57
 diff -u -u -p -r1.57 tty_tty.c
 --- sys/kern/tty_tty.c	8 Aug 2005 19:55:32 -0000	1.57
 +++ sys/kern/tty_tty.c	17 Dec 2005 06:23:13 -0000
 @@ -64,6 +64,10 @@ ctty_clone(void *arg, struct ucred *cred
   		*dev = ctty;
   	else if (curthread->td_proc->p_session->s_ttyvp == NULL)
   		*dev = ctty;
 +	else if (curthread->td_proc->p_session->s_ttyvp->v_type == VBAD)
 +		return;		/* e.g. s_ttyvp was revoked */
 +	else if (curthread->td_proc->p_session->s_ttyvp->v_rdev == NULL)
 +		return;		/* another effect of revocation */
   	else
   		*dev = curthread->td_proc->p_session->s_ttyvp->v_rdev;
   	dev_ref(*dev);
 
 -- 
 Nate Eldredge
 nge@cs.hmc.edu

From: Marc Olzheim <marcolz@stack.nl>
To: FreeBSD-gnats-submit@FreeBSD.org
Cc: Marc Olzheim <marcolz@stack.nl>, freebsd-bugs@FreeBSD.org
Subject: Re: kern/83375: Fatal trap 12 cloning a pty
Date: Tue, 2 May 2006 13:51:01 +0200

 The patch seems to work against crashes. :-)
 
 Marc
Responsible-Changed-From-To: phk->mbr 
Responsible-Changed-By: mbr 
Responsible-Changed-When: Sat Sep 23 13:50:22 UTC 2006 
Responsible-Changed-Why:  
I'll work on this 

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

From: dfilter@FreeBSD.ORG (dfilter service)
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/83375: commit references a PR
Date: Sat, 23 Sep 2006 14:44:31 +0000 (UTC)

 mbr         2006-09-23 14:44:15 UTC
 
   FreeBSD src repository
 
   Modified files:
     sys/kern             tty_tty.c 
   Log:
   If /dev/tty gets opened after your controlling terminal has been revoked
   you can't call tty_clone afterwords. OpenBSD and NetBSD both fail the
   open call in that case, so we should do so as well. This can
   be done in ctty_clone by returning with *dev==NULL. Admittedly this
   causes open to return ENOENT, instead of ENXIO as on the other BSDs,
   but this way requires the least touching of code.
   
   Submitted by:  Nate Eldredge <nge@cs.hmc.edu>
   PR:            83375
   
   MFC:           1 week
   
   Revision  Changes    Path
   1.58      +5 -1      src/sys/kern/tty_tty.c
 _______________________________________________
 cvs-all@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/cvs-all
 To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org"
 
State-Changed-From-To: open->closed 
State-Changed-By: linimon 
State-Changed-When: Fri Feb 29 00:54:22 UTC 2008 
State-Changed-Why:  
Committed to RELENG_7 Sat Sep 23 2006 and MFCed to RELENG_6 Fri Sep 29 2006. 

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