linux-stable.git/drivers/tty/vt, branch v4.9.166

vt: invoke notifier on screen size change

2019-01-31T07:12:36+00:00

commit 0c9b1965faddad7534b6974b5b36c4ad37998f8e upstream.

User space using poll() on /dev/vcs devices are not awaken when a
screen size change occurs. Let's fix that.

Signed-off-by: Nicolas Pitre 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman

tty: vt_ioctl: fix potential Spectre v1

2018-09-29T10:07:34+00:00

commit e97267cb4d1ee01ca0929638ec0fcbb0904f903d upstream.

vsa.console is indirectly controlled by user-space, hence leading to
a potential exploitation of the Spectre variant 1 vulnerability.

This issue was detected with the help of Smatch:

drivers/tty/vt/vt_ioctl.c:711 vt_ioctl() warn: potential spectre issue
'vc_cons' [r]

Fix this by sanitizing vsa.console before using it to index vc_cons

Notice that given that speculation windows are large, the policy is
to kill the speculation on the first load and not worry if it can be
completed with a dependent load/store [1].

[1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2

Cc: stable@vger.kernel.org
Signed-off-by: Gustavo A. R. Silva 
Reviewed-by: Alan Cox 
Signed-off-by: Greg Kroah-Hartman

vt: prevent leaking uninitialized data to userspace via /dev/vcs*

2018-07-11T14:26:42+00:00

commit 21eff69aaaa0e766ca0ce445b477698dc6a9f55a upstream.

KMSAN reported an infoleak when reading from /dev/vcs*:

  BUG: KMSAN: kernel-infoleak in vcs_read+0x18ba/0x1cc0
  Call Trace:
  ...
   kmsan_copy_to_user+0x7a/0x160 mm/kmsan/kmsan.c:1253
   copy_to_user ./include/linux/uaccess.h:184
   vcs_read+0x18ba/0x1cc0 drivers/tty/vt/vc_screen.c:352
   __vfs_read+0x1b2/0x9d0 fs/read_write.c:416
   vfs_read+0x36c/0x6b0 fs/read_write.c:452
  ...
  Uninit was created at:
   kmsan_save_stack_with_flags mm/kmsan/kmsan.c:279
   kmsan_internal_poison_shadow+0xb8/0x1b0 mm/kmsan/kmsan.c:189
   kmsan_kmalloc+0x94/0x100 mm/kmsan/kmsan.c:315
   __kmalloc+0x13a/0x350 mm/slub.c:3818
   kmalloc ./include/linux/slab.h:517
   vc_allocate+0x438/0x800 drivers/tty/vt/vt.c:787
   con_install+0x8c/0x640 drivers/tty/vt/vt.c:2880
   tty_driver_install_tty drivers/tty/tty_io.c:1224
   tty_init_dev+0x1b5/0x1020 drivers/tty/tty_io.c:1324
   tty_open_by_driver drivers/tty/tty_io.c:1959
   tty_open+0x17b4/0x2ed0 drivers/tty/tty_io.c:2007
   chrdev_open+0xc25/0xd90 fs/char_dev.c:417
   do_dentry_open+0xccc/0x1440 fs/open.c:794
   vfs_open+0x1b6/0x2f0 fs/open.c:908
  ...
  Bytes 0-79 of 240 are uninitialized

Consistently allocating |vc_screenbuf| with kzalloc() fixes the problem

Reported-by: syzbot+17a8efdf800000@syzkaller.appspotmail.com
Signed-off-by: Alexander Potapenko 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman

vt: change SGR 21 to follow the standards

2018-04-08T10:12:58+00:00

commit 65d9982d7e523a1a8e7c9af012da0d166f72fc56 upstream.

ECMA-48 [1] (aka ISO 6429) has defined SGR 21 as "doubly underlined"
since at least March 1984.  The Linux kernel has treated it as SGR 22
"normal intensity" since it was added in Linux-0.96b in June 1992.
Before that, it was simply ignored.  Other terminal emulators have
either ignored it, or treat it as double underline now.  xterm for
example added support in its 304 release (May 2014) [2] where it was
previously ignoring it.

Changing this behavior shouldn't be an issue:
- It isn't a named capability in ncurses's terminfo database, so no
  script is using libtinfo/libcurses to look this up, or using tput
  to query & output the right sequence.
- Any script assuming SGR 21 will reset intensity in all terminals
  already do not work correctly on non-Linux VTs (including running
  under screen/tmux/etc...).
- If someone has written a script that only runs in the Linux VT, and
  they're using SGR 21 (instead of SGR 22), the output should still
  be readable.

imo it's important to change this as the Linux VT's non-conformance
is sometimes used as an argument for other terminal emulators to not
implement SGR 21 at all, or do so incorrectly.

[1]: https://www.ecma-international.org/publications/standards/Ecma-048.htm
[2]: https://github.com/ThomasDickey/xterm-snapshots/commit/2fd29cb98d214cb536bcafbee00bc73b3f1eeb9d

Signed-off-by: Mike Frysinger 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman

tty: vt: fix up tabstops properly

2018-03-28T16:39:24+00:00

commit f1869a890cdedb92a3fab969db5d0fd982850273 upstream.

Tabs on a console with long lines do not wrap properly, so correctly
account for the line length when computing the tab placement location.

Reported-by: James Holderness 
Signed-off-by: Greg Kroah-Hartman 
Cc: stable 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

vt: fix unchecked __put_user() in tioclinux ioctls

2017-07-21T05:42:22+00:00

commit 6987dc8a70976561d22450b5858fc9767788cc1c upstream.

Only read access is checked before this call.

Actually, at the moment this is not an issue, as every in-tree arch does
the same manual checks for VERIFY_READ vs VERIFY_WRITE, relying on the MMU
to tell them apart, but this wasn't the case in the past and may happen
again on some odd arch in the future.

If anyone cares about 3.7 and earlier, this is a security hole (untested)
on real 80386 CPUs.

Signed-off-by: Adam Borowski 
Signed-off-by: Greg Kroah-Hartman

vt: fix Scroll Lock LED trigger name

2017-01-09T07:32:21+00:00

commit 31b5929d533f5183972cf57a7844b456ed996f3c upstream.

There is a disagreement between drivers/tty/vt/keyboard.c and
drivers/input/input-leds.c with regard to what is a Scroll Lock LED
trigger name: input calls it "kbd-scrolllock", but vt calls it
"kbd-scrollock" (two l's).
This prevents Scroll Lock LED trigger from binding to this LED by default.

Since it is a scroLL Lock LED, this interface was introduced only about a
year ago and in an Internet search people seem to reference this trigger
only to set it to this LED let's simply rename it to "kbd-scrolllock".

Also, it looks like this was supposed to be changed before this code was
merged: https://lkml.org/lkml/2015/6/9/697 but it was done only on
the input side.

Signed-off-by: Maciej S. Szmigiero 
Acked-by: Samuel Thibault 
Signed-off-by: Greg Kroah-Hartman

vt: clear selection before resizing

2016-10-27T15:19:35+00:00

When resizing a vt its selection may exceed the new size, resulting in
an invalid memory access [1]. Clear the selection before resizing.

[1] http://lkml.kernel.org/r/CACT4Y+acDTwy4umEvf5ROBGiRJNrxHN4Cn5szCXE5Jw-d1B=Xw@mail.gmail.com

Reported-and-tested-by: Dmitry Vyukov 
Signed-off-by: Scot Doyle 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman

tty: limit terminal size to 4M chars

2016-10-27T14:41:56+00:00

Size of kmalloc() in vc_do_resize() is controlled by user.
Too large kmalloc() size triggers WARNING message on console.
Put a reasonable upper bound on terminal size to prevent WARNINGs.

Signed-off-by: Dmitry Vyukov 
CC: David Rientjes 
Cc: One Thousand Gnomes 
Cc: Greg Kroah-Hartman 
Cc: Jiri Slaby 
Cc: Peter Hurley 
Cc: linux-kernel@vger.kernel.org
Cc: syzkaller@googlegroups.com
Cc: stable 
Signed-off-by: Greg Kroah-Hartman

tty: vt, fix bogus division in csi_J

2016-10-27T14:00:31+00:00

In csi_J(3), the third parameter of scr_memsetw (vc_screenbuf_size) is
divided by 2 inappropriatelly. But scr_memsetw expects size, not
count, because it divides the size by 2 on its own before doing actual
memset-by-words.

So remove the bogus division.

Signed-off-by: Jiri Slaby 
Cc: Petr Písař 
Fixes: f8df13e0a9 (tty: Clean console safely)
Signed-off-by: Greg Kroah-Hartman