Re: [PATCH] pty: fix use after free of tty->driver_data

From: Herton R. Krzesinski
Date: Tue Dec 15 2015 - 15:34:31 EST


On Tue, Dec 15, 2015 at 11:52:14AM -0800, Peter Hurley wrote:
> On 12/15/2015 11:23 AM, Herton R. Krzesinski wrote:
> > On Tue, Dec 15, 2015 at 04:05:09PM -0200, Herton R. Krzesinski wrote:
> >> On Tue, Dec 15, 2015 at 09:36:26AM -0800, Peter Hurley wrote:
> >>>
> >>>
> >>>> Signed-off-by: Herton R. Krzesinski <herton@xxxxxxxxxx>
> >>>> Cc: <stable@xxxxxxxxxxxxxxx>
> >>>
> >>> Afaict, the stable tag goes back to the original implementation.
> >>> Did you research how far back the /dev/tty alias problem goes?
> >>
> >> Hmm no. I did cc stable because the first report I got about this issue
> >> was on RHEL 7 with 3.10 based kernel, so this issue goes far back
> >> some releases that are still supported and similar code is there.
> >>
> >> On a quick check on a 2.6.32 kernel, things were very different,
> >> tty_release_dev() called directly devpts_kill_index with inode
> >> from the same file being closed. I'll check more and adjust the tag.
> >
> > FYI, checked here and the problem should start with 3.8, after commit
> > fa2ecfc5a68d85624bbd84f7d010860776b7e602 devpts_kill_index was moved
> > to pty.c/pty_unix98_shutdown
> >
>
> istm this goes back to multi-instance devpts support added in 2.6.28.
>
> Before then, there was no inode parameter because there was only
> one devpts instance and the idas were global.

Yeah, I'm not ruling out problems with devpts instances prior to 3.8, where to
me the wrong inode will be given in the final close with /dev/tty case, when the
ptmx is on a different instance other than the main ptmx instance (
pts_sb_from_inode will choose the "root"/main devpts instance, as the /dev/tty
inode usually is inode tied to devtmpfs mount at /dev). Both fa2ecfc5a68d85624b
and the new fix could be backported to 3.7 and as far as 2.6.28 perhaps, not
sure if anything else will be needed, however may not be worth the trouble.

--
[]'s
Herton
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/