Messages in this thread | | | Subject | Re: [PATCH] vt: vt_ioctl: fix VT_DISALLOCATE freeing in-use virtual console | From | Jiri Slaby <> | Date | Mon, 24 Feb 2020 09:04:33 +0100 |
| |
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
| |