From owner-freebsd-hackers@FreeBSD.ORG  Tue Nov  1 16:10:43 2005
Return-Path: <owner-freebsd-hackers@FreeBSD.ORG>
X-Original-To: freebsd-hackers@freebsd.org
Delivered-To: freebsd-hackers@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id BD56E16A41F
	for <freebsd-hackers@freebsd.org>; Tue,  1 Nov 2005 16:10:43 +0000 (GMT)
	(envelope-from uvarovsl@mail.pnpi.spb.ru)
Received: from mail.lsi.ru (mail.lsi.ru [212.58.192.30])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 5543F43D49
	for <freebsd-hackers@freebsd.org>; Tue,  1 Nov 2005 16:10:42 +0000 (GMT)
	(envelope-from uvarovsl@mail.pnpi.spb.ru)
Received: by mail.lsi.ru (Postfix, from userid 426)
	id D128A387734; Tue,  1 Nov 2005 19:10:39 +0300 (MSK)
Received: from [10.0.0.10] (unknown [212.58.210.222])
	by mail.lsi.ru (Postfix) with ESMTP id 886EA3877EE
	for <freebsd-hackers@freebsd.org>; Tue,  1 Nov 2005 19:10:39 +0300 (MSK)
Message-ID: <43679365.6050502@mail.pnpi.spb.ru>
Date: Tue, 01 Nov 2005 19:10:13 +0300
From: Sergey Uvarov <uvarovsl@mail.pnpi.spb.ru>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.7.12) Gecko/20050923 Fedora/1.7.12-1.5.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: freebsd-hackers@freebsd.org
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: about PR kern/83375
X-BeenThere: freebsd-hackers@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Technical Discussions relating to FreeBSD
	<freebsd-hackers.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-hackers>, 
	<mailto:freebsd-hackers-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-hackers>
List-Post: <mailto:freebsd-hackers@freebsd.org>
List-Help: <mailto:freebsd-hackers-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-hackers>,
	<mailto:freebsd-hackers-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Nov 2005 16:10:43 -0000

Hello hackers,

yesterday, while playing with ptys on 5.3 kernel, I was hit by bug 
#83375. I have reproduced it quite easely:

% /usr/libexec/getty Pc ttyp2 &

% /usr/libexec/getty Pc ttyp2

--- kernel panic ----

ttyp2 - not used slave pty

I was curious and did some investigation why it happens. As result, I 
have found the source of bug. Please, look at this:

What does getty(8) do with specified device? It basically does the 
following steps:

- chmod(name)
- chmod(name)
- revoke(name)
- open(name)

First invocation of getty(8) does not revoke anything, and just goes to 
sleep in ptsopen().

Second invocation of getty(8) also does revoke(2) first. But in this 
case, revoke syscall calls ptsclose() routine. So we have the following 
call chain:

ptsclose()->tty_close()->ttyrel().

tty ref for ttyp2 is still equal to 1, since the first invocation of 
getty(8) sleeps awaiting for a master, and tty_open is not called yet.
Hence, ttyrel() above simply frees tty struct for the ttyp2.

After that, getty(8) calls open(2) which in turn calls ptsopen(). But 
due to tty struct is already destroyed, the following branch works while 
it should not:

if (tp->t_oproc)
	(void)ttyld_modem(tp, 1)

It happens because freed space is filled with 0xdeadcode pattern (I'm 
using debug kernel version). As result, we have a crash in ttyld_modem().

How to fix it? It seems that one should not call tty_close() in 
ptsclose() if tty ref == 1. It not tested however.

What do hackers think about it?

Thank you,
	Sergey.