lkml.org 
[lkml]   [2020]   [Feb]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] vt: vt_ioctl: fix VT_DISALLOCATE freeing in-use virtual console
From
Date
On 24. 02. 20, 8:12, Eric Biggers wrote:
> From: Eric Biggers <ebiggers@google.com>
>
> The VT_DISALLOCATE ioctl can free a virtual console while tty_release()
> is still running, causing a use-after-free in con_shutdown(). This
> occurs because VT_DISALLOCATE only considers a virtual console to be
> in-use if it has a tty_struct with count > 0. But actually when
> count == 0, the tty is still in the process of being closed.
>
> Fix this by treating a virtual console as in-use if it has a tty_struct
> at all, even with zero count; and by making VT_DISALLOCATE take the
> tty_mutex in order to provide synchronization with release_tty().
>
> Reproducer:
> #include <fcntl.h>
> #include <linux/vt.h>
> #include <sys/ioctl.h>
> #include <unistd.h>
>
> int main()
> {
> if (fork()) {
> for (;;)
> close(open("/dev/tty5", O_RDWR));
> } else {
> int fd = open("/dev/tty10", O_RDWR);
>
> for (;;)
> ioctl(fd, VT_DISALLOCATE, 5);
> }
> }
>
> 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?

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*.)

> if (VT_BUSY(vc_num))
> ret = -EBUSY;
> else if (vc_num)
> vc = vc_deallocate(vc_num);
> console_unlock();
> + mutex_unlock(&tty_mutex);
>
> if (vc && vc_num >= MIN_NR_CONSOLES) {
> tty_port_destroy(&vc->port);

thanks,
--
js
suse labs

\
 
 \ /
  Last update: 2020-02-24 09:04    [W:0.135 / U:24.768 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site