This one has been reported before.
n_tty_receive_buf() puts a character into the tty queue and
then calls con_flush_chars(), which touches tty->driver_data.
Problem is, there's a window between these two operations where the
device can be closed (especially if the char is "^D"!), and con_close()
will zero out tty->driver_data. Hence null pointer deref.
I don't really believe this explanation, because the timing's
wrong - the reader isn't woken until after the flush is called.
Hence it'll be very difficult to actually trigger this race.
It's probably something else. But a bit more sticking plaster
should make it appear to be fixed:
--- linux-2.4.12-ac3/drivers/char/console.c Mon Oct 15 16:04:23 2001
+++ ac/drivers/char/console.c Sun Oct 21 08:19:42 2001
@@ -2387,9 +2387,15 @@ static void con_flush_chars(struct tty_s
return;
pm_access(pm_con);
- acquire_console_sem();
- set_cursor(vt->vc_num);
- release_console_sem();
+ if (vt) {
+ /*
+ * If we raced with con_close(), `vt' may be null.
+ * Hence this bandaid. - akpm
+ */
+ acquire_console_sem();
+ set_cursor(vt->vc_num);
+ release_console_sem();
+ }
}
/*
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/