about PR kern/83375

Sergey Uvarov uvarovsl at mail.pnpi.spb.ru
Tue Nov 1 08:10:43 PST 2005

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:


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,

More information about the freebsd-hackers mailing list