1. 24 6月, 2020 14 次提交
  2. 10 6月, 2020 1 次提交
  3. 27 5月, 2020 1 次提交
    • D
      vt: keyboard: avoid signed integer overflow in k_ascii · b86dab05
      Dmitry Torokhov 提交于
      When k_ascii is invoked several times in a row there is a potential for
      signed integer overflow:
      
      UBSAN: Undefined behaviour in drivers/tty/vt/keyboard.c:888:19 signed integer overflow:
      10 * 1111111111 cannot be represented in type 'int'
      CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.6.11 #1
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
      Call Trace:
       <IRQ>
       __dump_stack lib/dump_stack.c:77 [inline]
       dump_stack+0xce/0x128 lib/dump_stack.c:118
       ubsan_epilogue+0xe/0x30 lib/ubsan.c:154
       handle_overflow+0xdc/0xf0 lib/ubsan.c:184
       __ubsan_handle_mul_overflow+0x2a/0x40 lib/ubsan.c:205
       k_ascii+0xbf/0xd0 drivers/tty/vt/keyboard.c:888
       kbd_keycode drivers/tty/vt/keyboard.c:1477 [inline]
       kbd_event+0x888/0x3be0 drivers/tty/vt/keyboard.c:1495
      
      While it can be worked around by using check_mul_overflow()/
      check_add_overflow(), it is better to introduce a separate flag to
      signal that number pad is being used to compose a symbol, and
      change type of the accumulator from signed to unsigned, thus
      avoiding undefined behavior when it overflows.
      Reported-by: NKyungtae Kim <kt0755@gmail.com>
      Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
      Cc: stable <stable@vger.kernel.org>
      Link: https://lore.kernel.org/r/20200525232740.GA262061@dtor-wsSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b86dab05
  4. 04 5月, 2020 1 次提交
  5. 23 4月, 2020 2 次提交
  6. 16 4月, 2020 2 次提交
  7. 27 3月, 2020 2 次提交
    • E
      vt: vt_ioctl: fix use-after-free in vt_in_use() · 7cf64b18
      Eric Biggers 提交于
      vt_in_use() dereferences console_driver->ttys[i] without proper locking.
      This is broken because the tty can be closed and freed concurrently.
      
      We could fix this by using 'READ_ONCE(console_driver->ttys[i]) != NULL'
      and skipping the check of tty_struct::count.  But, looking at
      console_driver->ttys[i] isn't really appropriate anyway because even if
      it is NULL the tty can still be in the process of being closed.
      
      Instead, fix it by making vt_in_use() require console_lock() and check
      whether the vt is allocated and has port refcount > 1.  This works since
      following the patch "vt: vt_ioctl: fix VT_DISALLOCATE freeing in-use
      virtual console" the port refcount is incremented while the vt is open.
      
      Reproducer (very unreliable, but it worked for me after a few minutes):
      
      	#include <fcntl.h>
      	#include <linux/vt.h>
      
      	int main()
      	{
      		int fd, nproc;
      		struct vt_stat state;
      		char ttyname[16];
      
      		fd = open("/dev/tty10", O_RDONLY);
      		for (nproc = 1; nproc < 8; nproc *= 2)
      			fork();
      		for (;;) {
      			sprintf(ttyname, "/dev/tty%d", rand() % 8);
      			close(open(ttyname, O_RDONLY));
      			ioctl(fd, VT_GETSTATE, &state);
      		}
      	}
      
      KASAN report:
      
      	BUG: KASAN: use-after-free in vt_in_use drivers/tty/vt/vt_ioctl.c:48 [inline]
      	BUG: KASAN: use-after-free in vt_ioctl+0x1ad3/0x1d70 drivers/tty/vt/vt_ioctl.c:657
      	Read of size 4 at addr ffff888065722468 by task syz-vt2/132
      
      	CPU: 0 PID: 132 Comm: syz-vt2 Not tainted 5.6.0-rc5-00130-g089b6d36 #13
      	Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20191223_100556-anatol 04/01/2014
      	Call Trace:
      	 [...]
      	 vt_in_use drivers/tty/vt/vt_ioctl.c:48 [inline]
      	 vt_ioctl+0x1ad3/0x1d70 drivers/tty/vt/vt_ioctl.c:657
      	 tty_ioctl+0x9db/0x11b0 drivers/tty/tty_io.c:2660
      	 [...]
      
      	Allocated by task 136:
      	 [...]
      	 kzalloc include/linux/slab.h:669 [inline]
      	 alloc_tty_struct+0x96/0x8a0 drivers/tty/tty_io.c:2982
      	 tty_init_dev+0x23/0x350 drivers/tty/tty_io.c:1334
      	 tty_open_by_driver drivers/tty/tty_io.c:1987 [inline]
      	 tty_open+0x3ca/0xb30 drivers/tty/tty_io.c:2035
      	 [...]
      
      	Freed by task 41:
      	 [...]
      	 kfree+0xbf/0x200 mm/slab.c:3757
      	 free_tty_struct+0x8d/0xb0 drivers/tty/tty_io.c:177
      	 release_one_tty+0x22d/0x2f0 drivers/tty/tty_io.c:1468
      	 process_one_work+0x7f1/0x14b0 kernel/workqueue.c:2264
      	 worker_thread+0x8b/0xc80 kernel/workqueue.c:2410
      	 [...]
      
      Fixes: 4001d7b7 ("vt: push down the tty lock so we can see what is left to tackle")
      Cc: <stable@vger.kernel.org> # v3.4+
      Acked-by: NJiri Slaby <jslaby@suse.cz>
      Signed-off-by: NEric Biggers <ebiggers@google.com>
      Link: https://lore.kernel.org/r/20200322034305.210082-3-ebiggers@kernel.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7cf64b18
    • 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
  8. 16 3月, 2020 4 次提交
  9. 13 3月, 2020 2 次提交
  10. 06 3月, 2020 6 次提交
  11. 28 2月, 2020 2 次提交
    • J
      vt: selection, push sel_lock up · e8c75a30
      Jiri Slaby 提交于
      sel_lock cannot nest in the console lock. Thanks to syzkaller, the
      kernel states firmly:
      
      > WARNING: possible circular locking dependency detected
      > 5.6.0-rc3-syzkaller #0 Not tainted
      > ------------------------------------------------------
      > syz-executor.4/20336 is trying to acquire lock:
      > ffff8880a2e952a0 (&tty->termios_rwsem){++++}, at: tty_unthrottle+0x22/0x100 drivers/tty/tty_ioctl.c:136
      >
      > but task is already holding lock:
      > ffffffff89462e70 (sel_lock){+.+.}, at: paste_selection+0x118/0x470 drivers/tty/vt/selection.c:374
      >
      > which lock already depends on the new lock.
      >
      > the existing dependency chain (in reverse order) is:
      >
      > -> #2 (sel_lock){+.+.}:
      >        mutex_lock_nested+0x1b/0x30 kernel/locking/mutex.c:1118
      >        set_selection_kernel+0x3b8/0x18a0 drivers/tty/vt/selection.c:217
      >        set_selection_user+0x63/0x80 drivers/tty/vt/selection.c:181
      >        tioclinux+0x103/0x530 drivers/tty/vt/vt.c:3050
      >        vt_ioctl+0x3f1/0x3a30 drivers/tty/vt/vt_ioctl.c:364
      
      This is ioctl(TIOCL_SETSEL).
      Locks held on the path: console_lock -> sel_lock
      
      > -> #1 (console_lock){+.+.}:
      >        console_lock+0x46/0x70 kernel/printk/printk.c:2289
      >        con_flush_chars+0x50/0x650 drivers/tty/vt/vt.c:3223
      >        n_tty_write+0xeae/0x1200 drivers/tty/n_tty.c:2350
      >        do_tty_write drivers/tty/tty_io.c:962 [inline]
      >        tty_write+0x5a1/0x950 drivers/tty/tty_io.c:1046
      
      This is write().
      Locks held on the path: termios_rwsem -> console_lock
      
      > -> #0 (&tty->termios_rwsem){++++}:
      >        down_write+0x57/0x140 kernel/locking/rwsem.c:1534
      >        tty_unthrottle+0x22/0x100 drivers/tty/tty_ioctl.c:136
      >        mkiss_receive_buf+0x12aa/0x1340 drivers/net/hamradio/mkiss.c:902
      >        tty_ldisc_receive_buf+0x12f/0x170 drivers/tty/tty_buffer.c:465
      >        paste_selection+0x346/0x470 drivers/tty/vt/selection.c:389
      >        tioclinux+0x121/0x530 drivers/tty/vt/vt.c:3055
      >        vt_ioctl+0x3f1/0x3a30 drivers/tty/vt/vt_ioctl.c:364
      
      This is ioctl(TIOCL_PASTESEL).
      Locks held on the path: sel_lock -> termios_rwsem
      
      > other info that might help us debug this:
      >
      > Chain exists of:
      >   &tty->termios_rwsem --> console_lock --> sel_lock
      
      Clearly. From the above, we have:
       console_lock -> sel_lock
       sel_lock -> termios_rwsem
       termios_rwsem -> console_lock
      
      Fix this by reversing the console_lock -> sel_lock dependency in
      ioctl(TIOCL_SETSEL). First, lock sel_lock, then console_lock.
      Signed-off-by: NJiri Slaby <jslaby@suse.cz>
      Reported-by: syzbot+26183d9746e62da329b8@syzkaller.appspotmail.com
      Fixes: 07e6124a ("vt: selection, close sel_buffer race")
      Cc: stable <stable@vger.kernel.org>
      Link: https://lore.kernel.org/r/20200228115406.5735-2-jslaby@suse.czSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e8c75a30
    • J
      vt: selection, push console lock down · 4b70dd57
      Jiri Slaby 提交于
      We need to nest the console lock in sel_lock, so we have to push it down
      a bit. Fortunately, the callers of set_selection_* just lock the console
      lock around the function call. So moving it down is easy.
      
      In the next patch, we switch the order.
      Signed-off-by: NJiri Slaby <jslaby@suse.cz>
      Fixes: 07e6124a ("vt: selection, close sel_buffer race")
      Cc: stable <stable@vger.kernel.org>
      Link: https://lore.kernel.org/r/20200228115406.5735-1-jslaby@suse.czSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4b70dd57
  12. 21 2月, 2020 2 次提交
  13. 14 2月, 2020 1 次提交
    • J
      vt: selection, close sel_buffer race · 07e6124a
      Jiri Slaby 提交于
      syzkaller reported this UAF:
      BUG: KASAN: use-after-free in n_tty_receive_buf_common+0x2481/0x2940 drivers/tty/n_tty.c:1741
      Read of size 1 at addr ffff8880089e40e9 by task syz-executor.1/13184
      
      CPU: 0 PID: 13184 Comm: syz-executor.1 Not tainted 5.4.7 #1
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014
      Call Trace:
      ...
       kasan_report+0xe/0x20 mm/kasan/common.c:634
       n_tty_receive_buf_common+0x2481/0x2940 drivers/tty/n_tty.c:1741
       tty_ldisc_receive_buf+0xac/0x190 drivers/tty/tty_buffer.c:461
       paste_selection+0x297/0x400 drivers/tty/vt/selection.c:372
       tioclinux+0x20d/0x4e0 drivers/tty/vt/vt.c:3044
       vt_ioctl+0x1bcf/0x28d0 drivers/tty/vt/vt_ioctl.c:364
       tty_ioctl+0x525/0x15a0 drivers/tty/tty_io.c:2657
       vfs_ioctl fs/ioctl.c:47 [inline]
      
      It is due to a race between parallel paste_selection (TIOCL_PASTESEL)
      and set_selection_user (TIOCL_SETSEL) invocations. One uses sel_buffer,
      while the other frees it and reallocates a new one for another
      selection. Add a mutex to close this race.
      
      The mutex takes care properly of sel_buffer and sel_buffer_lth only. The
      other selection global variables (like sel_start, sel_end, and sel_cons)
      are protected only in set_selection_user. The other functions need quite
      some more work to close the races of the variables there. This is going
      to happen later.
      
      This likely fixes (I am unsure as there is no reproducer provided) bug
      206361 too. It was marked as CVE-2020-8648.
      Signed-off-by: NJiri Slaby <jslaby@suse.cz>
      Reported-by: syzbot+59997e8d5cbdc486e6f6@syzkaller.appspotmail.com
      References: https://bugzilla.kernel.org/show_bug.cgi?id=206361
      Cc: stable <stable@vger.kernel.org>
      Link: https://lore.kernel.org/r/20200210081131.23572-2-jslaby@suse.czSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      07e6124a