linux-stable.git/drivers/tty, branch v4.19.9

kgdboc: fix KASAN global-out-of-bounds bug in param_set_kgdboc_var()

2018-12-13T08:16:22+00:00

commit dada6a43b0402eba438a17ac86fdc64ac56a4607 upstream.

This patch is trying to fix KE issue due to
"BUG: KASAN: global-out-of-bounds in param_set_kgdboc_var+0x194/0x198"
reported by Syzkaller scan."

[26364:syz-executor0][name:report8t]BUG: KASAN: global-out-of-bounds in param_set_kgdboc_var+0x194/0x198
[26364:syz-executor0][name:report&]Read of size 1 at addr ffffff900e44f95f by task syz-executor0/26364
[26364:syz-executor0][name:report&]
[26364:syz-executor0]CPU: 7 PID: 26364 Comm: syz-executor0 Tainted: G W 0
[26364:syz-executor0]Call trace:
[26364:syz-executor0][] dump_bacIctrace+Ox0/0x470
[26364:syz-executor0][] show_stack+0x20/0x30
[26364:syz-executor0][] dump_stack+Oxd8/0x128
[26364:syz-executor0][] print_address_description +0x80/0x4a8
[26364:syz-executor0][] kasan_report+Ox178/0x390
[26364:syz-executor0][] _asan_report_loadi_noabort+Ox18/0x20
[26364:syz-executor0][] param_set_kgdboc_var+Ox194/0x198
[26364:syz-executor0][] param_attr_store+Ox14c/0x270
[26364:syz-executor0][] module_attr_store+0x60/0x90
[26364:syz-executor0][] sysfs_kl_write+Ox100/0x158
[26364:syz-executor0][] kernfs_fop_write+0x27c/0x3a8
[26364:syz-executor0][] do_loop_readv_writev+0x114/0x1b0
[26364:syz-executor0][] do_readv_writev+0x4f8/0x5e0
[26364:syz-executor0][] vfs_writev+0x7c/Oxb8
[26364:syz-executor0][] SyS_writev+Oxcc/0x208
[26364:syz-executor0][] elO_svc_naked +0x24/0x28
[26364:syz-executor0][name:report&]
[26364:syz-executor0][name:report&]The buggy address belongs to the variable:
[26364:syz-executor0][name:report&] kgdb_tty_line+Ox3f/0x40
[26364:syz-executor0][name:report&]
[26364:syz-executor0][name:report&]Memory state around the buggy address:
[26364:syz-executor0] ffffff900e44f800: 00 00 00 00 00 04 fa fa fa fa fa fa 00 fa fa fa
[26364:syz-executor0] ffffff900e44f880: fa fa fa fa 00 fa fa fa fa fa fa fa 00 fa fa fa
[26364:syz-executor0]> ffffff900e44f900: fa fa fa fa 04 fa fa fa fa fa fa fa 00 00 00 00
[26364:syz-executor0][name:report&]                                       ^
[26364:syz-executor0] ffffff900e44f980: 00 fa fa fa fa fa fa fa 04 fa fa fa fa fa fa fa
[26364:syz-executor0] ffffff900e44fa00: 04 fa fa fa fa fa fa fa 00 fa fa fa fa fa fa fa
[26364:syz-executor0][name:report&]
[26364:syz-executor0][name:panic&]Disabling lock debugging due to kernel taint
[26364:syz-executor0]------------[cut here]------------

After checking the source code, we've found there might be an out-of-bounds
access to "config[len - 1]" array when the variable "len" is zero.

Signed-off-by: Macpaul Lin 
Acked-by: Daniel Thompson 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Greg Kroah-Hartman

tty: do not set TTY_IO_ERROR flag if console port

2018-12-13T08:16:22+00:00

commit 2a48602615e0a2f563549c7d5c8d507f904cf96e upstream.

Since Commit 761ed4a94582 ('tty: serial_core: convert uart_close to use
tty_port_close') and Commit 4dda864d7307 ('tty: serial_core: Fix serial
console crash on port shutdown), a serial port which is used as
console can be stuck when logging out if there is a remained process.
After logged out, agetty will try to grab the serial port but it will
be failed because the previous process did not release the port
correctly. To fix this, TTY_IO_ERROR bit should not be enabled of
tty_port_close if the port is console port.

Reproduce step:
- Run background processes from serial console
$ while true; do sleep 10; done &

- Log out
$ logout
-> Stuck

- Read journal log by journalctl | tail
Jan 28 16:07:01 ubuntu systemd[1]: Stopped Serial Getty on ttyAMA0.
Jan 28 16:07:01 ubuntu systemd[1]: Started Serial Getty on ttyAMA0.
Jan 28 16:07:02 ubuntu agetty[1643]: /dev/ttyAMA0: not a tty

Fixes: 761ed4a94582 ("tty: serial_core: convert uart_close to use tty_port_close")
Cc: Geert Uytterhoeven 
Cc: Rob Herring 
Cc: Jiri Slaby 
Signed-off-by: Chanho Park 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman

tty: serial: 8250_mtk: always resume the device in probe.

2018-12-13T08:16:22+00:00

commit 100bc3e2bebf95506da57cbdf5f26b25f6da4c81 upstream.

serial8250_register_8250_port calls uart_config_port, which calls
config_port on the port before it tries to power on the port. So we need
the port to be on before calling serial8250_register_8250_port. Change
the code to always do a runtime resume in probe before registering port,
and always do a runtime suspend in remove.

This basically reverts the change in commit 68e5fc4a255a ("tty: serial:
8250_mtk: use pm_runtime callbacks for enabling"), but still use
pm_runtime callbacks.

Fixes: 68e5fc4a255a ("tty: serial: 8250_mtk: use pm_runtime callbacks for enabling")
Signed-off-by: Peter Shih 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman

USB: serial: console: fix reported terminal settings

2018-12-13T08:16:15+00:00

commit f51ccf46217c28758b1f3b5bc0ccfc00eca658b2 upstream.

The USB-serial console implementation has never reported the actual
terminal settings used. Despite storing the corresponding cflags in its
struct console, these were never honoured on later tty open() where the
tty termios would be left initialised to the driver defaults.

Unlike the serial console implementation, the USB-serial code calls
subdriver open() already at console setup. While calling set_termios()
and write() before open() looks like it could work for some USB-serial
drivers, others definitely do not expect this, so modelling this after
serial core is going to be intrusive, if at all possible.

Instead, use a (renamed) tty helper to save the termios data used at
console setup so that the tty termios reflects the actual terminal
settings after a subsequent tty open().

Note that the calls to tty_init_termios() (tty_driver_install()) and
tty_save_termios() are serialised using the disconnect mutex.

This specifically fixes a regression that was triggered by a recent
change adding software flow control to the pl2303 driver: a getty trying
to disable flow control while leaving the baud rate unchanged would now
also set the baud rate to the driver default (prior to the flow-control
change this had been a noop).

Fixes: 7041d9c3f01b ("USB: serial: pl2303: add support for tx xon/xoff flow control")
Cc: stable 	# 4.18
Cc: Florian Zumbiehl 
Reported-by: Jarkko Nikula 
Tested-by: Jarkko Nikula 
Acked-by: Greg Kroah-Hartman 
Signed-off-by: Johan Hovold 
Signed-off-by: Greg Kroah-Hartman

kgdboc: Fix warning with module build

2018-12-08T11:59:08+00:00

commit 1cd25cbb2fedbc777f3a8c3cb1ba69b645aeaa64 upstream.

After 2dd453168643 ("kgdboc: Fix restrict error"), kgdboc_option_setup is
now only used when built in, resulting in a warning when compiled as a
module:

drivers/tty/serial/kgdboc.c:134:12: warning: 'kgdboc_option_setup' defined but not used [-Wunused-function]
 static int kgdboc_option_setup(char *opt)
            ^~~~~~~~~~~~~~~~~~~

Move the function under the appropriate ifdef for builtin only.

Fixes: 2dd453168643 ("kgdboc: Fix restrict error")
Reported-by: Stephen Rothwell 
Signed-off-by: Laura Abbott 
Signed-off-by: Greg Kroah-Hartman

kgdboc: Fix restrict error

2018-12-08T11:59:08+00:00

commit 2dd453168643d9475028cd867c57e65956a0f7f9 upstream.

There's an error when compiled with restrict:

drivers/tty/serial/kgdboc.c: In function ‘configure_kgdboc’:
drivers/tty/serial/kgdboc.c:137:2: error: ‘strcpy’ source argument is the same
as destination [-Werror=restrict]
  strcpy(config, opt);
  ^~~~~~~~~~~~~~~~~~~

As the error implies, this is from trying to use config as both source and
destination. Drop the call to the function where config is the argument
since nothing else happens in the function.

Signed-off-by: Laura Abbott 
Reviewed-by: Daniel Thompson 
Signed-off-by: Greg Kroah-Hartman

tty: wipe buffer if not echoing data

2018-12-01T08:37:34+00:00

commit b97b3d9fb57860a60592859e332de7759fd54c2e upstream.

If we are not echoing the data to userspace or the console is in icanon
mode, then perhaps it is a "secret" so we should wipe it once we are
done with it.

This mirrors the logic that the audit code has.

Reported-by: aszlig 
Tested-by: Milan Broz 
Tested-by: Daniel Zatovic 
Tested-by: aszlig 
Cc: Willy Tarreau 
Signed-off-by: Greg Kroah-Hartman

tty: wipe buffer.

2018-12-01T08:37:34+00:00

commit c9a8e5fce009e3c601a43c49ea9dbcb25d1ffac5 upstream.

After we are done with the tty buffer, zero it out.

Reported-by: aszlig 
Tested-by: Milan Broz 
Tested-by: Daniel Zatovic 
Tested-by: aszlig 
Cc: Willy Tarreau 
Signed-off-by: Greg Kroah-Hartman

serial: sh-sci: Fix receive on SCIFA/SCIFB variants with DMA

2018-11-27T15:13:01+00:00

[ Upstream commit 202dc3cc10b4d37e5251431acf8d5040a8876c7d ]

On SCIFA and SCIFB serial ports with DMA support (i.e. some ports on
R-Car Gen2 and RZ/G1 SoCs), receive DMA operations are submitted before
the DMA channel pointer is initialized.  Hence this fails, and the
driver tries to fall back to PIO.  However, at this early phase in the
initialization sequence, fallback to PIO does not work, leading to a
serial port that cannot receive any data.

Fix this by calling sci_submit_rx() after initialization of the DMA
channel pointer.

Reported-by: Yoshihiro Shimoda 
Fixes: 2c4ee23530ffc022 ("serial: sh-sci: Postpone DMA release when falling back to PIO")
Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Wolfram Sang 
Tested-by: Wolfram Sang 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

termios, tty/tty_baudrate.c: fix buffer overrun

2018-11-21T08:19:20+00:00

commit 991a25194097006ec1e0d2e0814ff920e59e3465 upstream.

On architectures with CBAUDEX == 0 (Alpha and PowerPC), the code in tty_baudrate.c does
not do any limit checking on the tty_baudrate[] array, and in fact a
buffer overrun is possible on both architectures. Add a limit check to
prevent that situation.

This will be followed by a much bigger cleanup/simplification patch.

Signed-off-by: H. Peter Anvin (Intel) 
Requested-by: Cc: Johan Hovold 
Cc: Jiri Slaby 
Cc: Al Viro 
Cc: Richard Henderson 
Cc: Ivan Kokshaysky 
Cc: Matt Turner 
Cc: Thomas Gleixner 
Cc: Kate Stewart 
Cc: Philippe Ombredanne 
Cc: Eugene Syromiatnikov 
Cc: Alan Cox 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman