Date: Tue, 01 Nov 2005 19:10:13 +0300 From: Sergey Uvarov <uvarovsl@mail.pnpi.spb.ru> To: freebsd-hackers@freebsd.org Subject: about PR kern/83375 Message-ID: <43679365.6050502@mail.pnpi.spb.ru>
next in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?43679365.6050502>