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

serial: core: mark port as initialized after successful IRQ change

2018-02-13T11:35:56+00:00

commit 44117a1d1732c513875d5a163f10d9adbe866c08 upstream.

setserial changes the IRQ via uart_set_info(). It invokes
uart_shutdown() which free the current used IRQ and clear
TTY_PORT_INITIALIZED. It will then update the IRQ number and invoke
uart_startup() before returning to the caller leaving
TTY_PORT_INITIALIZED cleared.

The next open will crash with
|  list_add double add: new=ffffffff839fcc98, prev=ffffffff839fcc98, next=ffffffff839fcc98.
since the close from the IOCTL won't free the IRQ (and clean the list)
due to the TTY_PORT_INITIALIZED check in uart_shutdown().

There is same pattern in uart_do_autoconfig() and I *think* it also
needs to set TTY_PORT_INITIALIZED there.
Is there a reason why uart_startup() does not set the flag by itself
after the IRQ has been acquired (since it is cleared in uart_shutdown)?

Signed-off-by: Sebastian Andrzej Siewior 
Signed-off-by: Greg Kroah-Hartman

serial: imx: Only wakeup via RTSDEN bit if the system has RTS/CTS

2018-02-03T16:05:43+00:00

commit 38b1f0fb42f772b8c9aac53593883a18ff5eb9d7 upstream.

The wakeup mechanism via RTSDEN bit relies on the system using the RTS/CTS
lines, so only allow such wakeup method when the system actually has
RTS/CTS support.

Fixes: bc85734b126f ("serial: imx: allow waking up on RTSD")
Signed-off-by: Fabio Estevam 
Reviewed-by: Martin Kaiser 
Acked-by: Fugang Duan 
Signed-off-by: Greg Kroah-Hartman

tty: fix data race between tty_init_dev and flush of buf

2018-02-03T16:05:41+00:00

commit b027e2298bd588d6fa36ed2eda97447fb3eac078 upstream.

There can be a race, if receive_buf call comes before
tty initialization completes in n_tty_open and tty->disc_data
may be NULL.

CPU0					CPU1
----					----
 000|n_tty_receive_buf_common()   	n_tty_open()
-001|n_tty_receive_buf2()		tty_ldisc_open.isra.3()
-002|tty_ldisc_receive_buf(inline)	tty_ldisc_setup()

Using ldisc semaphore lock in tty_init_dev till disc_data
initializes completely.

Signed-off-by: Gaurav Kohli 
Reviewed-by: Alan Cox 
Signed-off-by: Greg Kroah-Hartman

tty: fix tty_ldisc_receive_buf() documentation

2018-01-02T19:35:17+00:00

commit e7e51dcf3b8a5f65c5653a054ad57eb2492a90d0 upstream.

The tty_ldisc_receive_buf() helper returns the number of bytes
processed so drop the bogus "not" from the kernel doc comment.

Fixes: 8d082cd300ab ("tty: Unify receive_buf() code paths")
Signed-off-by: Johan Hovold 
Signed-off-by: Greg Kroah-Hartman

n_tty: fix EXTPROC vs ICANON interaction with TIOCINQ (aka FIONREAD)

2018-01-02T19:35:17+00:00

commit 966031f340185eddd05affcf72b740549f056348 upstream.

We added support for EXTPROC back in 2010 in commit 26df6d13406d ("tty:
Add EXTPROC support for LINEMODE") and the intent was to allow it to
override some (all?) ICANON behavior.  Quoting from that original commit
message:

         There is a new bit in the termios local flag word, EXTPROC.
         When this bit is set, several aspects of the terminal driver
         are disabled.  Input line editing, character echo, and mapping
         of signals are all disabled.  This allows the telnetd to turn
         off these functions when in linemode, but still keep track of
         what state the user wants the terminal to be in.

but the problem turns out that "several aspects of the terminal driver
are disabled" is a bit ambiguous, and you can really confuse the n_tty
layer by setting EXTPROC and then causing some of the ICANON invariants
to no longer be maintained.

This fixes at least one such case (TIOCINQ) becoming unhappy because of
the confusion over whether ICANON really means ICANON when EXTPROC is set.

This basically makes TIOCINQ match the case of read: if EXTPROC is set,
we ignore ICANON.  Also, make sure to reset the ICANON state ie EXTPROC
changes, not just if ICANON changes.

Fixes: 26df6d13406d ("tty: Add EXTPROC support for LINEMODE")
Reported-by: Tetsuo Handa 
Reported-by: syzkaller 
Cc: Jiri Slaby 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

tty: fix data race in tty_ldisc_ref_wait()

2017-12-20T09:07:26+00:00

[ Upstream commit a4a3e061149f09c075f108b6f1cf04d9739a6bc2 ]

tty_ldisc_ref_wait() checks tty->ldisc under tty->ldisc_sem.
But if ldisc==NULL it releases them sem and reloads
tty->ldisc without holding the sem. This is wrong and
can lead to returning non-NULL ldisc without protection.

Don't reload tty->ldisc second time.

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

tty: don't panic on OOM in tty_set_ldisc()

2017-12-20T09:07:25+00:00

[ Upstream commit 5362544bebe85071188dd9e479b5a5040841c895 ]

If tty_ldisc_open() fails in tty_set_ldisc(), it tries to go back
to the old discipline or N_TTY. But that can fail as well, in such
case it panics. This is not a graceful way to handle OOM.

Leave ldisc==NULL if all attempts fail instead.
Also use existing tty_ldisc_reinit() helper function instead of
tty_ldisc_restore(). Also don't WARN/BUG in tty_ldisc_reinit()
if N_TTY fails, which would have the same net effect of bringing
kernel down on OOM. Instead print a single line message about
what has happened.

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

sysrq : fix Show Regs call trace on ARM

2017-12-09T21:01:49+00:00

[ Upstream commit b00bebbc301c8e1f74f230dc82282e56b7e7a6db ]

When kernel configuration SMP,PREEMPT and DEBUG_PREEMPT are enabled,
echo 1 >/proc/sys/kernel/sysrq
echo p >/proc/sysrq-trigger
kernel will print call trace as below:

sysrq: SysRq : Show Regs
BUG: using __this_cpu_read() in preemptible [00000000] code: sh/435
caller is __this_cpu_preempt_check+0x18/0x20
Call trace:
[] dump_backtrace+0x0/0x1d0
[] show_stack+0x24/0x30
[] dump_stack+0x90/0xb0
[] check_preemption_disabled+0x100/0x108
[] __this_cpu_preempt_check+0x18/0x20
[] sysrq_handle_showregs+0x1c/0x40
[] __handle_sysrq+0x12c/0x1a0
[] write_sysrq_trigger+0x60/0x70
[] proc_reg_write+0x90/0xd0
[] __vfs_write+0x48/0x90
[] vfs_write+0xa4/0x190
[] SyS_write+0x54/0xb0
[] el0_svc_naked+0x24/0x28

This can be seen on a common board like an r-pi3.
This happens because when echo p >/proc/sysrq-trigger,
get_irq_regs() is called outside of IRQ context,
if preemption is enabled in this situation,kernel will
print the call trace. Since many prior discussions on
the mailing lists have made it clear that get_irq_regs
either just returns NULL or stale data when used outside
of IRQ context,we simply avoid calling it outside of
IRQ context.

Signed-off-by: Jibin Xu 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

serial: 8250: Preserve DLD[7:4] for PORT_XR17V35X

2017-12-09T21:01:48+00:00

[ Upstream commit 0ab84da2e076948c49d36197ee7d254125c53eab ]

The upper four bits of the XR17V35x fractional divisor register (DLD)
control general chip function (RS-485 direction pin polarity, multidrop
mode, XON/XOFF parity check, and fast IR mode). Don't allow these bits
to be clobbered when setting the baudrate.

Signed-off-by: Aaron Sierra 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

serial: 8250_fintek: Fix rs485 disablement on invalid ioctl()

2017-12-09T21:01:48+00:00

[ Upstream commit 3236a965486ba0c6043cf2c7b51943d8b382ae29 ]

This driver's ->rs485_config callback checks if SER_RS485_RTS_ON_SEND
and SER_RS485_RTS_AFTER_SEND have the same value.  If they do, it means
the user has passed in invalid data with the TIOCSRS485 ioctl()
since RTS must have a different polarity when sending and when not
sending.  In this case, rs485 mode is not enabled (the RS485_URA bit
is not set in the RS485 Enable Register) and this is supposed to be
signaled back to the user by clearing the SER_RS485_ENABLED bit in
struct serial_rs485 ... except a missing tilde character is preventing
that from happening.

Fixes: 28e3fb6c4dce ("serial: Add support for Fintek F81216A LPC to 4 UART")
Cc: Ricardo Ribalda Delgado 
Cc: "Ji-Ze Hong (Peter Hong)" 
Signed-off-by: Lukas Wunner 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman