From: Steven Rostedt <rostedt@goodmis.org>

While debugging Ingo's RT patch, I came accross this race condition.
The mainline seems to be susceptible to this bug, although it may be 1
in a 1,000,000 to happen. But those are the nastiest races.

With debugging information in the RT patch, I was able to reproduce this
race several times. Enough to be able to debug it. 

The race is with the tty->driver_data, tty->count and vt.c

Here's the scoop:

Process P1 opens a tty:
  tty_open 
    --> init_dev
          sets tty->count to 1

P1 does what it needs to, and closes the tty.
  tty_release  (now showing locks)
    (grabs BKL)
    --> release_dev
        --> tty->driver->close ==> con_close (vt.c)
            (down tty_sem)
            (aquire console_sem)
            tty->driver_data = NULL

Now process P2 opens the console:
   tty_open
      (block on tty_sem)

back to P1
         (release console_sem)
         (up tty_sem)

back to P2
       (down tty_sem)
       --> init_dev
           tty->count++ (tty->count now == 2)
           (up tty_sem)
           --> tty->driver->open ==> con_open (vt.c)
              (aquire console_sem)
               if (tty->count == 1) (which it does not)
                    allocate tty->driver_data
                          (which doesn't happen)
              (release console_sem)
  
     And P2 goes happily along with driver_data == NULL.

Now in something like vt_ioctl (which I first saw the bug)

int vt_ioctl(struct tty_struct *tty, struct file * file,
	     unsigned int cmd, unsigned long arg)
{
	struct vc_data *vc = (struct vc_data *)tty->driver_data;
	struct console_font_op op;	/* used in multiple places here */
	struct kbd_struct * kbd;
	unsigned int console;
	unsigned char ucval;
	void __user *up = (void __user *)arg;
	int i, perm;
	
	console = vc->vc_num;

Where here vc->vc_num could very well be (0)->vc_num.

I googled a little and found where this may have already happened in the
main line kernel:

http://seclists.org/lists/linux-kernel/2005/Aug/1603.html

So here's my proposal: 

  Instead of checking for tty->count == 1 in con_open, which we see is
not reliable.  Just check for tty->driver_data == NULL.

This should work since it should always be NULL when we need to assign
it.  If we switch the events of the race, so that the init_dev went
first, the driver_data would not be NULL and would not need to be
allocated, because after init_dev tty->count would be greater than 1
(this is assuming the case that it is already allocated) and the
con_close would not deallocate it.  The tty_sem and console_sem and
order of events protect the tty->driver_data but not the tty->count.

Without the patch, I was able to get the system to BUG on bootup every
other time.  With the patch applied, I was able to bootup 6 out of 6
times without a single crash. 

Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
---

 drivers/char/vt.c |    2 +-
 1 files changed, 1 insertion(+), 1 deletion(-)

diff -puN drivers/char/vt.c~race-condition-with-drivers-char-vtc-bug-in-vt_ioctlc drivers/char/vt.c
--- devel/drivers/char/vt.c~race-condition-with-drivers-char-vtc-bug-in-vt_ioctlc	2005-08-21 23:48:37.000000000 -0700
+++ devel-akpm/drivers/char/vt.c	2005-08-21 23:48:37.000000000 -0700
@@ -2451,7 +2451,7 @@ static int con_open(struct tty_struct *t
 	int ret = 0;
 
 	acquire_console_sem();
-	if (tty->count == 1) {
+	if (tty->driver_data == NULL) {
 		ret = vc_allocate(currcons);
 		if (ret == 0) {
 			struct vc_data *vc = vc_cons[currcons].d;
_