From nobody@FreeBSD.org  Mon Feb 19 11:34:41 2001
Return-Path: <nobody@FreeBSD.org>
Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21])
	by hub.freebsd.org (Postfix) with ESMTP id C7A9837B401
	for <freebsd-gnats-submit@FreeBSD.org>; Mon, 19 Feb 2001 11:34:40 -0800 (PST)
Received: (from nobody@localhost)
	by freefall.freebsd.org (8.11.1/8.11.1) id f1JJYew70666;
	Mon, 19 Feb 2001 11:34:40 -0800 (PST)
	(envelope-from nobody)
Message-Id: <200102191934.f1JJYew70666@freefall.freebsd.org>
Date: Mon, 19 Feb 2001 11:34:40 -0800 (PST)
From: mm@omnix.net
To: freebsd-gnats-submit@FreeBSD.org
Subject: Kernel Panic
X-Send-Pr-Version: www-1.0

>Number:         25206
>Category:       kern
>Synopsis:       Kernel Panic
>Confidential:   no
>Severity:       critical
>Priority:       medium
>Responsible:    dwmalone
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Feb 19 11:40:01 PST 2001
>Closed-Date:    Mon Feb 26 03:02:22 PST 2001
>Last-Modified:  Mon Feb 26 03:02:49 PST 2001
>Originator:     Meadele Mathieu
>Release:        FreeBSD-4.2-Stable
>Organization:
-
>Environment:
FreeBSD PAF 4.2-RELEASE FreeBSD 4.2-RELEASE #9:
Wed Feb  7 22:01:11 CET 2001     
root@PAF:/usr/src/sys/compile/PAF  i386
>Description:
By default, /dev/ttyp* have perm set to 0666, until someone remotely
log in, in this case the user's ttyp is chmod'ed to 0600 and chown'ed
to this user.
if noone is remotely logged in, the next ttyp associated with telnet or 
ssh for example will be ttyp1.
My box crashed if a local user open the next /dev/ttyp normally used
for remote connection:

luser@PAF$ w
 8:37PM  up 32 mins, 2 users, load averages: 0.41, 0.17, 0.14
 USER             TTY      FROM              LOGIN@  IDLE WHAT
 luser            v0       -                 8:08PM     -  w
luser@PAF$ tail -f /dev/ttyp1

now ruser is going to connect to my box:
ruser@NOWHERE$ telnet PAF
Connection closed by foreign host.

luser@PAF$
 
 Fatal trap 12 = Page Fault while in kernel mode
 Fault virtual address = 0x88
 Fault code = supervisor read, page not present
 Instruction pointer = 0x8:0xc0167c1b
 Stack pointer = 0x10:0xd11f2ecc
 Frame pointer = 0x10:0xd11f2ed0
 Code segment = base 0x0, limit 0xfffff, type 0x1b
              = DLP 0, pres 1, def32 1, gran 1
 Processor eflags = interrupt enabled, resume, IO PL=0
 Current process = 257(tail)
 Interrupt mask = net tty bio cam
 trap number = 12
 panic = page fault

 syncing disk: 13 13 13 [...] 13 13
 giving up on 13 buffers

 uptime 32m36s
 Automatic reboot in 15 seconds...




Have you this problem on your box ?
It seems that a malicious local user can easily cause a denial 
of service like this.
>How-To-Repeat:
luser@A$ tail -f /dev/ttypx   (where ttypx is the next ttyp associated
                               with a remote connection)

ruser@B$ telnet A

-->machine A crashes

>Fix:


>Release-Note:
>Audit-Trail:

From: David Malone <dwmalone@maths.tcd.ie>
To: mm@omnix.net
Cc: freebsd-gnats-submit@FreeBSD.org, peter@FreeBSD.org,
	iedowse@maths.tcd.ie
Subject: Re: kern/25206: Kernel Panic
Date: Tue, 20 Feb 2001 14:03:29 +0000

 On Mon, Feb 19, 2001 at 11:34:40AM -0800, mm@omnix.net wrote:
 
 > luser@PAF$ tail -f /dev/ttyp1
 > 
 > now ruser is going to connect to my box:
 > ruser@NOWHERE$ telnet PAF
 > Connection closed by foreign host.
 
 This seems to be caused by kqueue trying to work on a revoked file
 discriptor. I think this bug is inaccessable in more recent versions
 of -stable after Peter's commit to vfs_vnops.c on 2001/02/09. The
 offending code looks like:
 
 static int
 filt_vnread(struct knote *kn, long hint)
 {
         struct vnode *vp = (struct vnode *)kn->kn_fp->f_data;
         struct inode *ip = VTOI(vp);
 
         kn->kn_data = ip->i_size - kn->kn_fp->f_offset;
         return (kn->kn_data != 0);
 }
 
 There is now a check to make sure that the file is in a UFS filesystem
 at the time the filter is attached. However, if the file is revoked
 it could change type, so checking something like:
 
 	if (vp->v_tag != VT_UFS)
 		return 1;
 
 might be a good idea. (Currently only device files can be revoked,
 but that's only 'cos it was disabeled on other file types 'cos it
 didn't work on fifos).
 
 	David.
Responsible-Changed-From-To: freebsd-bugs->dwmalone 
Responsible-Changed-By: dwmalone 
Responsible-Changed-When: Fri Feb 23 07:40:43 PST 2001 
Responsible-Changed-Why:  
This is the same bug as in 25309 - I'll try to get a fix reviewed for both. 
. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=25206 
State-Changed-From-To: open->closed 
State-Changed-By: dwmalone 
State-Changed-When: Mon Feb 26 03:02:22 PST 2001 
State-Changed-Why:  
I believe this has now been fixed in -stable. 

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