Re: [PATCH 1/2 v2] pty: fix possible use after free of tty->driver_data

[Peter Hurley]

On 01/14/2016 12:09 PM, Herton R. Krzesinski wrote:
> On Wed, Jan 13, 2016 at 10:28:44AM -0800, Josh Triplett wrote:
>> 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.

I'm ok with this fix for the moment because it's ideal for -stable;
simple, straightforward and addresses the one known use-case.


> Yeah, I thought previously as well that this should go to tty core (my thinking
> though was to get extra references to the opened files instead of the inode).
> 
> However, what inode should I choose to increment the reference count in the
> tty->tty_files list? I know most cases the device file will always be at the
> /dev, but if it's opened from another place/file?

I think the long-term solution would be to bump the inode ref at
controlling tty association because the appropriate inode is supplied for
either the ioctl(TIOCSCTTY) or the first qualifying open(). This inode
would be stored in the tty_struct, justifying the reference.

At dissociation, the inode reference would be dropped.

This approach also magically fixes the superblock pinning (because the inode
would be the slave inode so would be on the devpts fs, preventing umount).


> And handling this would overcomplicate a case which is pty specific, unless
> I miss something here pty is the only inode user, and seem not worth or
> useful to have at the moment this at tty core.

Any tty could be the process's controlling tty, and the tty core should be
pinning any fs objects related to that.

Regards,
Peter Hurley