lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 19 Mar 2007 22:40:39 -0800 From: Andrew Morton <akpm@...ux-foundation.org> To: spock@...too.org Cc: linux-kernel@...r.kernel.org Subject: Re: [PATCH] vt: fix a potential race in the VT_WAITACTIVE handler On Thu, 15 Mar 2007 15:10:23 +0100 Michal Januszewski <spock@...too.org> wrote: > On a multiprocessor machine the VT_WAITACTIVE ioctl call may return 0 > if fg_console has already been updated in redraw_screen(), but the > console switch itself hasn't been completed. Fix this by checking > fg_console in vt_waitactive() with the console sem held. > > Signed-off-by: Michal Januszewski <spock@...too.org> > > --- > diff --git a/drivers/char/vt_ioctl.c b/drivers/char/vt_ioctl.c > index 3a5d301..00b5b34 100644 > --- a/drivers/char/vt_ioctl.c > +++ b/drivers/char/vt_ioctl.c > @@ -1041,8 +1041,12 @@ int vt_waitactive(int vt) > for (;;) { > set_current_state(TASK_INTERRUPTIBLE); > retval = 0; > - if (vt == fg_console) > + acquire_console_sem(); > + if (vt == fg_console) { > + release_console_sem(); > break; > + } > + release_console_sem(); > retval = -EINTR; > if (signal_pending(current)) > break; > OK. I think. It's hard to tell. I assume that the acquire_console_sem() in here is to synchronise against some other function which also takes acquire_console_sem(), but it is not clear which. So could you please redo this with a comment which tells the reader exactly what's being protected against what, and why? Also, I always feel a bit worried by: set_current_state(TASK_INTERRUPTIBLE); down(...); because if it hits contention, the down() will undo the set_curremt_state(). Now that's normally OK because we loop, and because the semaphore won't normally be 100% contended all the time. Unless someone reimplements down() so it happens to return in state TASK_RUNNING all the time, which they could legitimately do (although this would probably break stuff such as the above). But still, it is nicer to do down(...); set_current_state(TASK_INTERRUPTIBLE); if possible, and I think it is possible here. Thanks. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists