linux.git/drivers/tty/tty_io.c, branch v5.2-rc2

tty: update obsolete termios comment

2019-04-25T09:58:56+00:00

Update an obsolete comment referring to the termios_locked structure
which was removed over a decade ago by commit fe6e29fdb1a7 ("tty:
simplify ktermios allocation").

While at it, fix the "Thus" typo.

Signed-off-by: Johan Hovold 
Signed-off-by: Greg Kroah-Hartman

Revert "tty: pty: Fix race condition between release_one_tty and pty_write"

2019-03-29T14:47:40+00:00

This reverts commit b9ca5f8560af244489b4a1bc1ae88b341f24bc95 as 0-day
shows it has a circular locking dependency.

Fixes: b9ca5f8560af ("tty: pty: Fix race condition between release_one_tty and pty_write")
Reported-by: kernel test robot 
Cc: Sahara 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman

tty: pty: Fix race condition between release_one_tty and pty_write

2019-03-27T16:28:23+00:00

Especially when a linked tty is used such as pty, the linked tty
port's buf works have not been cancelled while master tty port's
buf work has been cancelled. Since release_one_tty and flush_to_ldisc
run in workqueue threads separately, when pty_cleanup happens and
link tty port is freed, flush_to_ldisc tries to access freed port
and port->itty, eventually it causes a panic.
This patch utilizes the magic value with holding the tty_mutex to
check if the tty->link is valid.

Fixes: 2b022ab7542d ("pty: cancel pty slave port buf's work in tty_release")
Signed-off-by: Sahara 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman

tty: ldisc: add sysctl to prevent autoloading of ldiscs

2019-01-30T08:31:30+00:00

By default, the kernel will automatically load the module of any line
dicipline that is asked for.  As this sometimes isn't the safest thing
to do, provide a sysctl to disable this feature.

By default, we set this to 'y' as that is the historical way that Linux
has worked, and we do not want to break working systems.  But in the
future, perhaps this can default to 'n' to prevent this functionality.

Signed-off-by: Greg Kroah-Hartman 
Reviewed-by: Theodore Ts'o 
Signed-off-by: Greg Kroah-Hartman

tty: Handle problem if line discipline does not have receive_buf

2019-01-21T16:41:02+00:00

Some tty line disciplines do not have a receive buf callback, so
properly check for that before calling it.  If they do not have this
callback, just eat the character quietly, as we can't fail this call.

Reported-by: Jann Horn 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman

tty: Don't hold ldisc lock in tty_reopen() if ldisc present

2019-01-11T16:03:42+00:00

Try to get reference for ldisc during tty_reopen().
If ldisc present, we don't need to do tty_ldisc_reinit() and lock the
write side for line discipline semaphore.
Effectively, it optimizes fast-path for tty_reopen(), but more
importantly it won't interrupt ongoing IO on the tty as no ldisc change
is needed.
Fixes user-visible issue when tty_reopen() interrupted login process for
user with a long password, observed and reported by Lukas.

Fixes: c96cf923a98d ("tty: Don't block on IO when ldisc change is pending")
Fixes: 83d817f41070 ("tty: Hold tty_ldisc_lock() during tty_reopen()")
Cc: Jiri Slaby 
Reported-by: Lukas F. Hartmann 
Tested-by: Lukas F. Hartmann 
Cc: stable 
Signed-off-by: Dmitry Safonov 
Signed-off-by: Greg Kroah-Hartman

Merge 4.20-rc6 into tty-next

2018-12-10T09:17:45+00:00

We want the TTY changes in here as well.

Signed-off-by: Greg Kroah-Hartman

tty: Simplify tty->count math in tty_reopen()

2018-12-05T11:16:33+00:00

As notted by Jiri, tty_ldisc_reinit() shouldn't rely on tty counter.
Simplify math by increasing the counter after reinit success.

Cc: Jiri Slaby 
Link: lkml.kernel.org/r/<20180829022353.23568-2-dima@arista.com>
Suggested-by: Jiri Slaby 
Reviewed-by: Jiri Slaby 
Tested-by: Mark Rutland 
Signed-off-by: Dmitry Safonov 
Signed-off-by: Greg Kroah-Hartman

tty: Hold tty_ldisc_lock() during tty_reopen()

2018-12-05T11:16:33+00:00

tty_ldisc_reinit() doesn't race with neither tty_ldisc_hangup()
nor set_ldisc() nor tty_ldisc_release() as they use tty lock.
But it races with anyone who expects line discipline to be the same
after hoding read semaphore in tty_ldisc_ref().

We've seen the following crash on v4.9.108 stable:

BUG: unable to handle kernel paging request at 0000000000002260
IP: [..] n_tty_receive_buf_common+0x5f/0x86d
Workqueue: events_unbound flush_to_ldisc
Call Trace:
 [..] n_tty_receive_buf2
 [..] tty_ldisc_receive_buf
 [..] flush_to_ldisc
 [..] process_one_work
 [..] worker_thread
 [..] kthread
 [..] ret_from_fork

tty_ldisc_reinit() should be called with ldisc_sem hold for writing,
which will protect any reader against line discipline changes.

Cc: Jiri Slaby 
Cc: stable@vger.kernel.org # b027e2298bd5 ("tty: fix data race between tty_init_dev and flush of buf")
Reviewed-by: Jiri Slaby 
Reported-by: syzbot+3aa9784721dfb90e984d@syzkaller.appspotmail.com
Tested-by: Mark Rutland 
Tested-by: Tetsuo Handa 
Signed-off-by: Dmitry Safonov 
Tested-by: Tycho Andersen 
Signed-off-by: Greg Kroah-Hartman

USB: serial: console: fix reported terminal settings

2018-12-05T10:29:10+00:00

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