linux-stable.git/drivers/tty/tty_io.c, branch v5.3

tty: tty_io: fix driver refcount imbalance on error path

2019-05-24T08:09:12+00:00

tty_lookup_driver take a reference to the struct tty_driver, but forget
to release it on the error path, lead to a memory leak.
add a tty_driver_kref_put before error return.

Signed-off-by: Lin Yi 
Signed-off-by: Greg Kroah-Hartman

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