linux-kernel - Re: [PATCH] vt: vt_ioctl: fix VT_DISALLOCATE freeing in-use virtual console

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20200318222704.GC2334@sol.localdomain>
Date:   Wed, 18 Mar 2020 15:27:04 -0700
From:   Eric Biggers <ebiggers@...nel.org>
To:     Jiri Slaby <jslaby@...e.cz>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-kernel@...r.kernel.org, syzkaller-bugs@...glegroups.com,
        Eric Dumazet <edumazet@...gle.com>,
        Nicolas Pitre <nico@...xnic.net>,
        Alan Cox <gnomes@...rguk.ukuu.org.uk>
Subject: Re: [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