1. 24 6月, 2020 9 次提交
  2. 04 5月, 2020 1 次提交
  3. 23 4月, 2020 2 次提交
  4. 27 3月, 2020 1 次提交
    • E
      vt: vt_ioctl: fix VT_DISALLOCATE freeing in-use virtual console · ca4463bf
      Eric Biggers 提交于
      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 considers a virtual console's
      'struct vc_data' to be unused as soon as the corresponding tty's
      refcount hits 0.  But actually it may be still being closed.
      
      Fix this by making vc_data be reference-counted via the embedded
      'struct tty_port'.  A newly allocated virtual console has refcount 1.
      Opening it for the first time increments the refcount to 2.  Closing it
      for the last time decrements the refcount (in tty_operations::cleanup()
      so that it happens late enough), as does VT_DISALLOCATE.
      
      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
      	 [...]
      
      Fixes: 4001d7b7 ("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
      Acked-by: NJiri Slaby <jslaby@suse.cz>
      Signed-off-by: NEric Biggers <ebiggers@google.com>
      Link: https://lore.kernel.org/r/20200322034305.210082-2-ebiggers@kernel.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ca4463bf
  5. 16 3月, 2020 2 次提交
  6. 13 3月, 2020 1 次提交
  7. 28 2月, 2020 1 次提交
  8. 21 2月, 2020 1 次提交
  9. 11 2月, 2020 1 次提交
  10. 14 1月, 2020 3 次提交
  11. 25 7月, 2019 1 次提交
  12. 13 6月, 2019 2 次提交
  13. 24 5月, 2019 2 次提交
    • G
      vt/fbcon: deinitialize resources in visual_init() after failed memory allocation · a1ad1cc9
      Grzegorz Halat 提交于
      After memory allocation failure vc_allocate() doesn't clean up data
      which has been initialized in visual_init(). In case of fbcon this
      leads to divide-by-0 in fbcon_init() on next open of the same tty.
      
      memory allocation in vc_allocate() may fail here:
      1097:     vc->vc_screenbuf = kzalloc(vc->vc_screenbuf_size, GFP_KERNEL);
      
      on next open() fbcon_init() skips vc_font.data initialization:
      1088:     if (!p->fontdata) {
      
      division by zero in fbcon_init() happens here:
      1149:     new_cols /= vc->vc_font.width;
      
      Additional check is needed in fbcon_deinit() to prevent
      usage of uninitialized vc_screenbuf:
      
      1251:        if (vc->vc_hi_font_mask && vc->vc_screenbuf)
      1252:                set_vc_hi_font(vc, false);
      
      Crash:
      
       #6 [ffffc90001eafa60] divide_error at ffffffff81a00be4
          [exception RIP: fbcon_init+463]
          RIP: ffffffff814b860f  RSP: ffffc90001eafb18  RFLAGS: 00010246
      ...
       #7 [ffffc90001eafb60] visual_init at ffffffff8154c36e
       #8 [ffffc90001eafb80] vc_allocate at ffffffff8154f53c
       #9 [ffffc90001eafbc8] con_install at ffffffff8154f624
      ...
      Signed-off-by: NGrzegorz Halat <ghalat@redhat.com>
      Reviewed-by: NOleksandr Natalenko <oleksandr@redhat.com>
      Acked-by: NBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a1ad1cc9
    • G
      vt/fbcon: deinitialize resources in visual_init() after failed memory allocation · 5e309c6c
      Grzegorz Halat 提交于
      After memory allocation failure vc_allocate() doesn't clean up data
      which has been initialized in visual_init(). In case of fbcon this
      leads to divide-by-0 in fbcon_init() on next open of the same tty.
      
      memory allocation in vc_allocate() may fail here:
      1097:     vc->vc_screenbuf = kzalloc(vc->vc_screenbuf_size, GFP_KERNEL);
      
      on next open() fbcon_init() skips vc_font.data initialization:
      1088:     if (!p->fontdata) {
      
      division by zero in fbcon_init() happens here:
      1149:     new_cols /= vc->vc_font.width;
      
      Additional check is needed in fbcon_deinit() to prevent
      usage of uninitialized vc_screenbuf:
      
      1251:        if (vc->vc_hi_font_mask && vc->vc_screenbuf)
      1252:                set_vc_hi_font(vc, false);
      
      Crash:
      
       #6 [ffffc90001eafa60] divide_error at ffffffff81a00be4
          [exception RIP: fbcon_init+463]
          RIP: ffffffff814b860f  RSP: ffffc90001eafb18  RFLAGS: 00010246
      ...
       #7 [ffffc90001eafb60] visual_init at ffffffff8154c36e
       #8 [ffffc90001eafb80] vc_allocate at ffffffff8154f53c
       #9 [ffffc90001eafbc8] con_install at ffffffff8154f624
      ...
      Signed-off-by: NGrzegorz Halat <ghalat@redhat.com>
      Reviewed-by: NOleksandr Natalenko <oleksandr@redhat.com>
      Acked-by: NBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5e309c6c
  14. 19 4月, 2019 1 次提交
  15. 17 4月, 2019 1 次提交
    • M
      vt: fix cursor when clearing the screen · b2ecf006
      Mikulas Patocka 提交于
      The patch a6dbe442 ("vt: perform safe console erase in the right
      order") introduced a bug. The conditional do_update_region() was
      replaced by a call to update_region() that does contain the conditional
      already, but with unwanted extra side effects such as restoring the cursor
      drawing.
      
      In order to reproduce the bug:
      - use framebuffer console with the AMDGPU driver
      - type "links" to start the console www browser
      - press 'q' and space to exit links
      
      Now the cursor will be permanently visible in the center of the
      screen. It will stay there until something overwrites it.
      
      The bug goes away if we change update_region() back to the conditional
      do_update_region().
      
      [ nico: reworded changelog ]
      Signed-off-by: NMikulas Patocka <mpatocka@redhat.com>
      Reviewed-by: NNicolas Pitre <nico@fluxnic.net>
      Cc: stable@vger.kernel.org
      Fixes: a6dbe442 ("vt: perform safe console erase in the right order")
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b2ecf006
  16. 28 3月, 2019 1 次提交
    • Y
      tty: vt.c: Fix TIOCL_BLANKSCREEN console blanking if blankinterval == 0 · 75ddbc1f
      Yifeng Li 提交于
      Previously, in the userspace, it was possible to use the "setterm" command
      from util-linux to blank the VT console by default, using the following
      command.
      
      According to the man page,
      
      > The force option keeps the screen blank even if a key is pressed.
      
      It was implemented by calling TIOCL_BLANKSCREEN.
      
      	case BLANKSCREEN:
      		ioctlarg = TIOCL_BLANKSCREEN;
      		if (ioctl(STDIN_FILENO, TIOCLINUX, &ioctlarg))
      			warn(_("cannot force blank"));
      		break;
      
      However, after Linux 4.12, this command ceased to work anymore, which is
      unexpected. By inspecting the kernel source, it shows that the issue was
      triggered by the side-effect from commit a4199f5e ("tty: Disable
      default console blanking interval").
      
      The console blanking is implemented by function do_blank_screen() in vt.c:
      "blank_state" will be initialized to "blank_normal_wait" in con_init() if
      AND ONLY IF ("blankinterval" > 0). If "blankinterval" is 0, "blank_state"
      will be "blank_off" (== 0), and a call to do_blank_screen() will always
      abort, even if a forced blanking is required from the user by calling
      TIOCL_BLANKSCREEN, the console won't be blanked.
      
      This behavior is unexpected from a user's point-of-view, since it's not
      mentioned in any documentation. The setterm man page suggests it will
      always work, and the kernel comments in uapi/linux/tiocl.h says
      
      > /* keep screen blank even if a key is pressed */
      > #define TIOCL_BLANKSCREEN 14
      
      To fix it, we simply remove the "blank_state != blank_off" check, as
      pointed out by Nicolas Pitre, this check doesn't logically make sense
      and it's safe to remove.
      Suggested-by: NNicolas Pitre <nicolas.pitre@linaro.org>
      Fixes: a4199f5e ("tty: Disable default console blanking interval")
      Signed-off-by: NYifeng Li <tomli@tomli.me>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      75ddbc1f
  17. 12 2月, 2019 1 次提交
  18. 18 1月, 2019 9 次提交