linux-kernel - Re: [PATCH 0/2] SIGWINCH problem with terminal apps still alive

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20081012195957.50feada3@merlin.oi.pg.gda.pl>
Date:	Sun, 12 Oct 2008 19:59:57 +0200
From:	Adam Tlałka <atlka@...gda.pl>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	7eggert@....de, linux-kernel@...r.kernel.org, torvalds@...l.org
Subject: Re: [PATCH 0/2] SIGWINCH problem with terminal apps still alive

Sun, 12 Oct 2008 15:22:00 +0100 - Alan Cox <alan@...rguk.ukuu.org.uk>:

> O> real_tty structures. TIOCSWINSZ and TIOCGWINSZ ioctls could be
> > called on tty and real_tty at the same time. To avoid race condition
> 
> No they can't. Would you please bother to spend five minutes actually
> reading the source code and following through your assumptions to see
> if they make sense before posting.
> 
> tiocgwinsz is never called for the pty side of a pty pair.

I've read the code. The race problem with xterm or other pty using
program in 2.6.26 appeared because one app called ioctl(TIOCSWINSZ) on
the master side while other read winsize (TIOCGWINSZ) using client side
(slave). So in one ioctl() call tty == master and in other tty ==
real_tty. Of course we can have the opposite situaction so terminal app
is using ioctl(TIOCSWINSZ) on its side (slave) and xterm is using ioctl
on its side to know to which size resize itself. Not working now as I
tested but possible.

Anyway I think that you miss the point. Why using
real_tty->termios_mutex instead of tty->termios_mutex in tty_do_resize
called from tiocswins() so from ioctl(TIOCSWINSZ) closes the race. If as
you said tiocgwinsz is called on tty and not real_tty then
tty->termios_mutex should be valid here.
Mutexes work and it is not a scheduler problem as I wrongly assumed.
The scheduler just exposed this problem doing an app switch.
It's just wrong mutex used.

Look at the  tty_ioctl(struct file *file, unsigned int cmd, unsigned
long arg) in tty_io.c.

	tty = (struct tty_struct *)file->private_data;

so if you calling ioctl on master side we have tty = master
and on client side tty = real_tty in ioctl entry;
next

	real_tty = tty;
	if (tty->driver->type == TTY_DRIVER_TYPE_PTY &&
            tty->driver->subtype == PTY_TYPE_MASTER)
                real_tty = tty->link;

if tty is the master one we set real_tty but in case of client side
tty == real_tty already so real_tty points to the same structure.

So it seems that tty->termios_mutex could point to different
location in different calls but real_tty->termios_mutex always points
to the same location.

Regards

-- 
Adam Tlałka       mailto:atlka@...gda.pl    ^v^ ^v^ ^v^
System  & Network Administration Group       - - - ~~~~~~
Computer Center, Gdańsk University of Technology, Poland
--
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/