Bug 25206

Summary:	Kernel Panic
Product:	Base System	Reporter:	mm <mm>
Component:	kern	Assignee:	dwmalone
Status:	Closed FIXED
Severity:	Affects Only Me
Priority:	Normal
Version:	Unspecified
Hardware:	Any
OS:	Any

Description mm 2001-02-19 19:40:01 UTC

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 rx0, 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

Comment 1 dwmalone 2001-02-20 14:03:29 UTC

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.

Comment 2 dwmalone freebsd_committer

2001-02-23 15:40:43 UTC

Responsible Changed
From-To: freebsd-bugs->dwmalone

This is the same bug as in 25309 - I'll try to get a fix reviewed for both. 
.

Comment 3 dwmalone freebsd_committer

2001-02-26 11:02:22 UTC

State Changed
From-To: open->closed

I believe this has now been fixed in -stable.