From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753864AbbLOD3o (ORCPT ); Mon, 14 Dec 2015 22:29:44 -0500 Received: from mx1.redhat.com ([209.132.183.28]:36714 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753730AbbLOD3m (ORCPT ); Mon, 14 Dec 2015 22:29:42 -0500 From: "Herton R. Krzesinski" To: linux-kernel@vger.kernel.org Cc: Peter Hurley , Greg Kroah-Hartman , Jiri Slaby , herton@redhat.com Subject: [PATCH] pty: fix use after free of tty->driver_data Date: Tue, 15 Dec 2015 01:29:39 -0200 Message-Id: <1450150179-20925-2-git-send-email-herton@redhat.com> In-Reply-To: <1450150179-20925-1-git-send-email-herton@redhat.com> References: <1450150179-20925-1-git-send-email-herton@redhat.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org pty_unix98_shutdown allows a potential use after free of inode from slave tty->driver_data: if final pty close is called with slave tty_struct, and inode was released already by devpts_pty_kill at pty_close, pty_unix98_shutdown will access stale data. If the evicted inode is quickly reused again as another inode instance, this can potentially break in the case the inode is on a different devpts instance than the default devpts mount, not to mention a possible ops if the inode_cache slab is destroyed and reused as something else. Also there is an evident problem in case the last close is from a opened "/dev/tty" which points to the master/slave pty: since in this case any of the tty->driver_data can be stale, due to all references/ files being closed before (files related to ptmx/pts inodes set at tty->driver_data), we have the possibility of referencing an already freed inode. The fix here is to keep a reference on the opened master ptmx inode. We maintain the inode referenced until the final pty_unix98_shutdown, and only pass this inode to devpts_kill_index. Signed-off-by: Herton R. Krzesinski Cc: --- drivers/tty/pty.c | 18 +++++++++++++++++- 1 file changed, 17 insertions(+), 1 deletion(-) diff --git a/drivers/tty/pty.c b/drivers/tty/pty.c index a45660f..90743b0 100644 --- a/drivers/tty/pty.c +++ b/drivers/tty/pty.c @@ -681,7 +681,14 @@ static void pty_unix98_remove(struct tty_driver *driver, struct tty_struct *tty) /* this is called once with whichever end is closed last */ static void pty_unix98_shutdown(struct tty_struct *tty) { - devpts_kill_index(tty->driver_data, tty->index); + struct inode *ptmx_inode; + + if (tty->driver->subtype == PTY_TYPE_MASTER) + ptmx_inode = tty->driver_data; + else + ptmx_inode = tty->link->driver_data; + devpts_kill_index(ptmx_inode, tty->index); + iput(ptmx_inode); /* drop reference we acquired at ptmx_open */ } static const struct tty_operations ptm_unix98_ops = { @@ -773,6 +780,15 @@ static int ptmx_open(struct inode *inode, struct file *filp) set_bit(TTY_PTY_LOCK, &tty->flags); /* LOCK THE SLAVE */ tty->driver_data = inode; + /* + * In the rare case all references to ptmx inode are dropped (files + * closed), and we still have a device opened pointing to the + * master/slave pair (eg., "/dev/tty" opened), we must make sure that + * the inode is still valid when we call the final pty_unix98_shutdown: + * thus we must hold an additional reference to the ptmx inode here + */ + ihold(inode); + tty_add_file(tty, filp); slave_inode = devpts_pty_new(inode, -- 2.4.3