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 Wed, Mar 18, 2020 at 02:15:00PM +0100, Jiri Slaby wrote:
    > On 24. 02. 20, 9:19, 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.
    >
    > ...
    >
    > >> 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.
    >
    > Yes, but if it does the same as pty, i.e. throwing tty_port in
    > ->cleanup, not ->shutdown, that would work, right?
    >
    > The initial requirement from tty_port is that it outlives tty. This was
    > later lifted by pty to live at least till ->cleanup.
    >

    Yes, it looks like that will work. I didn't know about
    tty_operations::cleanup(). I'll update the patch.

    - Eric

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