From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756005AbcAMS2v (ORCPT ); Wed, 13 Jan 2016 13:28:51 -0500 Received: from relay4-d.mail.gandi.net ([217.70.183.196]:46745 "EHLO relay4-d.mail.gandi.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754874AbcAMS2t (ORCPT ); Wed, 13 Jan 2016 13:28:49 -0500 Date: Wed, 13 Jan 2016 10:28:44 -0800 From: Josh Triplett To: Peter Hurley Cc: "Herton R. Krzesinski" , Greg Kroah-Hartman , linux-kernel@vger.kernel.org, Alan Cox , Jiri Slaby , Andrew Morton , Al Viro , David Howells Subject: Re: [PATCH 1/2 v2] pty: fix possible use after free of tty->driver_data Message-ID: <20160113182844.GB8385@cloud> References: <1452521264-21766-1-git-send-email-herton@redhat.com> <1452521264-21766-2-git-send-email-herton@redhat.com> <56968BD1.5090000@hurleysoftware.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56968BD1.5090000@hurleysoftware.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jan 13, 2016 at 09:39:29AM -0800, Peter Hurley wrote: > On 01/11/2016 06:07 AM, Herton R. Krzesinski wrote: > > This change fixes a bug for a corner case where we have the the last > > release from a pty master/slave coming from a previously opened /dev/tty > > file. When this happens, the tty->driver_data can be stale, due to all > > ptmx or pts/N files having already been closed before (and thus the inode > > related to these files, which tty->driver_data points to, being already > > freed/destroyed). > > > > 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. > > Ideally, the tty core should be bumping the inode count for the underlying > controlling tty That does indeed sound like the right fix. /dev/tty doesn't act exactly like opening the underlying device (as it also supports the TIOCNOTTY ioctl), but it should definitely hold a reference to that underlying device.