TTY: make tty_add_file non-failing
authorJiri Slaby <jslaby@suse.cz>
Wed, 12 Oct 2011 09:32:43 +0000 (11:32 +0200)
committerGreg Kroah-Hartman <gregkh@suse.de>
Fri, 11 Nov 2011 17:42:12 +0000 (09:42 -0800)
commit5112c311dc253acd3c89c4b9fb69e200178c71a8
treee6fa4deb61207ea86460c4113c20d025453d0394
parentbebd46c74cf5d8c7d4972f543cafa0ee20b184f9
TTY: make tty_add_file non-failing

commit fa90e1c935472281de314e6d7c9a37db9cbc2e4e upstream.

If tty_add_file fails at the point it is now, we have to revert all
the changes we did to the tty. It means either decrease all refcounts
if this was a tty reopen or delete the tty if it was newly allocated.

There was a try to fix this in v3.0-rc2 using tty_release in 0259894c7
(TTY: fix fail path in tty_open). But instead it introduced a NULL
dereference. It's because tty_release dereferences
filp->private_data, but that one is set even in our tty_add_file. And
when tty_add_file fails, it's still NULL/garbage. Hence tty_release
cannot be called there.

To circumvent the original leak (and the current NULL deref) we split
tty_add_file into two functions, making the latter non-failing. In
that case we may do the former early in open, where handling failures
is easy. The latter stays as it is now. So there is no change in
functionality.

The original bug (leak) was introduced by f573bd176 (tty: Remove
__GFP_NOFAIL from tty_add_file()). Thanks Dan for reporting this.

Later, we may split tty_release into more functions and call only some
of them in this fail path instead. (If at all possible.)

Introduced-in: v2.6.37-rc2
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Pekka Enberg <penberg@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
drivers/tty/pty.c
drivers/tty/tty_io.c
include/linux/tty.h