lkml.org 
[lkml]   [2020]   [Mar]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] vt: vt_ioctl: fix VT_DISALLOCATE freeing in-use virtual console
On Mon, Mar 02, 2020 at 01:23:06PM -0800, Eric Biggers wrote:
> On Mon, Feb 24, 2020 at 12:19:13AM -0800, Eric Biggers wrote:
> > On Mon, Feb 24, 2020 at 09:04:33AM +0100, Jiri Slaby wrote:
> > > > KASAN report:
> > > > BUG: KASAN: use-after-free in con_shutdown+0x76/0x80 drivers/tty/vt/vt.c:3278
> > > > Write of size 8 at addr ffff88806a4ec108 by task syz_vt/129
> > > >
> > > > CPU: 0 PID: 129 Comm: syz_vt Not tainted 5.6.0-rc2 #11
> > > > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20191223_100556-anatol 04/01/2014
> > > > Call Trace:
> > > > [...]
> > > > con_shutdown+0x76/0x80 drivers/tty/vt/vt.c:3278
> > > > release_tty+0xa8/0x410 drivers/tty/tty_io.c:1514
> > > > tty_release_struct+0x34/0x50 drivers/tty/tty_io.c:1629
> > > > tty_release+0x984/0xed0 drivers/tty/tty_io.c:1789
> > > > [...]
> > > >
> > > > Allocated by task 129:
> > > > [...]
> > > > kzalloc include/linux/slab.h:669 [inline]
> > > > vc_allocate drivers/tty/vt/vt.c:1085 [inline]
> > > > vc_allocate+0x1ac/0x680 drivers/tty/vt/vt.c:1066
> > > > con_install+0x4d/0x3f0 drivers/tty/vt/vt.c:3229
> > > > tty_driver_install_tty drivers/tty/tty_io.c:1228 [inline]
> > > > tty_init_dev+0x94/0x350 drivers/tty/tty_io.c:1341
> > > > tty_open_by_driver drivers/tty/tty_io.c:1987 [inline]
> > > > tty_open+0x3ca/0xb30 drivers/tty/tty_io.c:2035
> > > > [...]
> > > >
> > > > Freed by task 130:
> > > > [...]
> > > > kfree+0xbf/0x1e0 mm/slab.c:3757
> > > > vt_disallocate drivers/tty/vt/vt_ioctl.c:300 [inline]
> > > > vt_ioctl+0x16dc/0x1e30 drivers/tty/vt/vt_ioctl.c:818
> > > > tty_ioctl+0x9db/0x11b0 drivers/tty/tty_io.c:2660
> > >
> > > That means the associated tty_port is destroyed while the tty layer
> > > still has a tty on the top of it. That is a BUG anyway.
> > >
> > > > Fixes: 4001d7b7fc27 ("vt: push down the tty lock so we can see what is left to tackle")
> > > > Cc: <stable@vger.kernel.org> # v3.4+
> > > > Reported-by: syzbot+522643ab5729b0421998@syzkaller.appspotmail.com
> > > > Signed-off-by: Eric Biggers <ebiggers@google.com>
> > > > ---
> > > > drivers/tty/vt/vt_ioctl.c | 6 +++++-
> > > > 1 file changed, 5 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/tty/vt/vt_ioctl.c b/drivers/tty/vt/vt_ioctl.c
> > > > index ee6c91ef1f6cf..57d681706fa85 100644
> > > > --- a/drivers/tty/vt/vt_ioctl.c
> > > > +++ b/drivers/tty/vt/vt_ioctl.c
> > > > @@ -42,7 +42,7 @@
> > > > char vt_dont_switch;
> > > > extern struct tty_driver *console_driver;
> > > >
> > > > -#define VT_IS_IN_USE(i) (console_driver->ttys[i] && console_driver->ttys[i]->count)
> > > > +#define VT_IS_IN_USE(i) (console_driver->ttys[i] != NULL)
> > > > #define VT_BUSY(i) (VT_IS_IN_USE(i) || i == fg_console || vc_cons[i].d == sel_cons)
> > > >
> > > > /*
> > > > @@ -288,12 +288,14 @@ static int vt_disallocate(unsigned int vc_num)
> > > > struct vc_data *vc = NULL;
> > > > int ret = 0;
> > > >
> > > > + mutex_lock(&tty_mutex); /* synchronize with release_tty() */
> > > > console_lock();
> > >
> > > Is this lock dependency new or pre-existing?
> >
> > It's the same locking order used during release_tty().
> >
> > >
> > > Locking tty_mutex here does not sound quite right. What about switching
> > > vc_data to proper refcounting based on tty_port? (Instead of doing
> > > tty_port_destroy and kfree in vt_disallocate*.)
> > >
> >
> > How would that work? We could make struct vc_data refcounted such that
> > VT_DISALLOCATE doesn't free it right away but rather it's freed in the next
> > con_shutdown(). But release_tty() still accesses tty->port afterwards, which is
> > part of the 'struct vc_data' that would have just been freed.
> >
>
> Jiri, can you explain what you meant here? I don't see how your suggestion
> would solve the problem.
>
> Greg, any opinion?

I'll defer to Jiri here :)

\
 
 \ /
  Last update: 2020-03-18 11:06    [W:2.551 / U:0.052 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site