linux-stable.git/drivers/tty/tty_io.c, branch linux-3.16.y

tty: Handle problem if line discipline does not have receive_buf

2019-05-02T20:41:26+00:00

commit 27cfb3a53be46a54ec5e0bd04e51995b74c90343 upstream.

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 
Signed-off-by: Greg Kroah-Hartman 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings

tty: Don't call panic() at tty_ldisc_init()

2018-10-21T07:45:38+00:00

commit 903f9db10f18f735e62ba447147b6c434b6af003 upstream.

syzbot is reporting kernel panic [1] triggered by memory allocation failure
at tty_ldisc_get() from tty_ldisc_init(). But since both tty_ldisc_get()
and caller of tty_ldisc_init() can cleanly handle errors, tty_ldisc_init()
does not need to call panic() when tty_ldisc_get() failed.

[1] https://syzkaller.appspot.com/bug?id=883431818e036ae6a9981156a64b821110f39187

Signed-off-by: Tetsuo Handa 
Reported-by: syzbot 
Cc: Greg Kroah-Hartman 
Cc: Jiri Slaby 
Signed-off-by: Greg Kroah-Hartman 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings

drivers: tty: Merge alloc_tty_struct and initialize_tty_struct

2018-10-21T07:45:37+00:00

commit 2c964a2f4191f2229566895f1a0e85f8339f5dd1 upstream.

The two functions alloc_tty_struct and initialize_tty_struct are
always called together. Merge them into alloc_tty_struct, updating its
prototype and the only two callers of these functions.

Signed-off-by: Rasmus Villemoes 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings

tty: Fix unsafe ldisc reference via ioctl(TIOCGETD)

2016-02-16T10:55:25+00:00

commit 5c17c861a357e9458001f021a7afa7aab9937439 upstream.

ioctl(TIOCGETD) retrieves the line discipline id directly from the
ldisc because the line discipline id (c_line) in termios is untrustworthy;
userspace may have set termios via ioctl(TCSETS*) without actually
changing the line discipline via ioctl(TIOCSETD).

However, directly accessing the current ldisc via tty->ldisc is
unsafe; the ldisc ptr dereferenced may be stale if the line discipline
is changing via ioctl(TIOCSETD) or hangup.

Wait for the line discipline reference (just like read() or write())
to retrieve the "current" line discipline id.

Signed-off-by: Peter Hurley 
Signed-off-by: Greg Kroah-Hartman 
Cc: Moritz Muehlenhoff 
Signed-off-by: Luis Henriques

tty: fix up atime/mtime mess, take four

2015-03-18T15:07:20+00:00

commit f0bf0bd07943bfde8f5ac39a32664810a379c7d3 upstream.

This problem was taken care of three times already in
* b0de59b5733d18b0d1974a060860a8b5c1b36a2e (TTY: do not update
  atime/mtime on read/write),
* 37b7f3c76595e23257f61bd80b223de8658617ee (TTY: fix atime/mtime
  regression), and
* b0b885657b6c8ef63a46bc9299b2a7715d19acde (tty: fix up atime/mtime
  mess, take three)

But it still misses one point. As John Paul correctly points out, we
do not care about setting date. If somebody ever changes wall
time backwards (by mistake for example), tty timestamps are never
updated until the original wall time passes.

So check the absolute difference of times and if it large than "8
seconds or so", always update the time. That means we will update
immediatelly when changing time. Ergo, CAP_SYS_TIME can foul the
check, but it was always that way.

Thanks John for serving me this so nicely debugged.

Signed-off-by: Jiri Slaby 
Reported-by: John Paul Perry 
Acked-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Luis Henriques

tty: Prevent "read/write wait queue active!" log flooding

2014-11-14T15:20:00+00:00

commit 494c1eac7e73f719af9d474a96ec8494c33efd6a upstream.

Only print one warning when a task is on the read_wait or write_wait
wait queue at final tty release.

Signed-off-by: Peter Hurley 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Luis Henriques

tty: Fix high cpu load if tty is unreleaseable

2014-11-14T15:20:00+00:00

commit 37b164578826406a173ca7c20d9ba7430134d23e upstream.

Kernel oops can cause the tty to be unreleaseable (for example, if
n_tty_read() crashes while on the read_wait queue). This will cause
tty_release() to endlessly loop without sleeping.

Use a killable sleep timeout which grows by 2n+1 jiffies over the interval
[0, 120 secs.) and then jumps to forever (but still killable).

NB: killable just allows for the task to be rewoken manually, not
to be terminated.

Signed-off-by: Peter Hurley 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Luis Henriques

tty: fix memleak in alloc_pid

2014-04-16T21:31:13+00:00

There is memleak in alloc_pid:
------------------------------
unreferenced object 0xd3453a80 (size 64):
  comm "adbd", pid 1730, jiffies 66363 (age 6586.950s)
  hex dump (first 32 bytes):
    01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    00 00 00 00 40 c2 f6 d5 00 d3 25 c1 59 28 00 00  ....@.....%.Y(..
  backtrace:
    [] kmemleak_alloc+0x3c/0xa0
    [] kmem_cache_alloc+0xc6/0x190
    [] alloc_pid+0x1e/0x400
    [] copy_process.part.39+0xad4/0x1120
    [] do_fork+0x99/0x330
    [] sys_fork+0x28/0x30
    [] syscall_call+0x7/0xb
    [] 0xffffffff

the leak is due to unreleased pid->count, which execute in function:
get_pid()(pid->count++) and put_pid()(pid->count--).

The race condition as following:
task[dumpsys]               task[adbd]
in disassociate_ctty()      in tty_signal_session_leader()
-----------------------     -------------------------
tty = get_current_tty();
// tty is not NULL
...
spin_lock_irq(¤t->sighand->siglock);
put_pid(current->signal->tty_old_pgrp);
current->signal->tty_old_pgrp = NULL;
spin_unlock_irq(¤t->sighand->siglock);

                            spin_lock_irq(&p->sighand->siglock);
                            ...
                            p->signal->tty = NULL;
                            ...
                            spin_unlock_irq(&p->sighand->siglock);

tty = get_current_tty();
// tty NULL, goto else branch by accident.
if (tty) {
    ...
    put_pid(tty_session);
    put_pid(tty_pgrp);
    ...
} else {
    print msg
}

in task[dumpsys], in disassociate_ctty(), tty is set NULL by task[adbd],
tty_signal_session_leader(), then it goto else branch and lack of
put_pid(), cause memleak.

move spin_unlock(sighand->siglock) after get_current_tty() can avoid
the race and fix the memleak.

Signed-off-by: Zhang Jun 
Signed-off-by: Chen Tingjie 
Signed-off-by: Greg Kroah-Hartman

tty: Set correct tty name in 'active' sysfs attribute

2014-03-01T00:36:46+00:00

The 'active' sysfs attribute should refer to the currently active tty
devices the console is running on, not the currently active console. The
console structure doesn't refer to any device in sysfs, only the tty the
console is running on has. So we need to print out the tty names in
'active', not the console names.

There is one special-case, which is tty0. If the console is directed to
it, we want 'tty0' to show up in the file, so user-space knows that the
messages get forwarded to the active VT. The ->device() callback would
resolve tty0, though. Hence, treat it special and don't call into the VT
layer to resolve it (plymouth is known to depend on it).

Cc: Lennart Poettering 
Cc: Kay Sievers 
Cc: Greg Kroah-Hartman 
Cc: Jiri Slaby 
Cc: stable 
Signed-off-by: Werner Fink 
Signed-off-by: Hannes Reinecke 
Signed-off-by: David Herrmann 
Signed-off-by: Greg Kroah-Hartman

Revert "tty: Set correct tty name in 'active' sysfs attribute"

2014-02-22T22:31:04+00:00

This reverts commit d8a5dc3033af2fd6d16030d2ee4fbd073460fe54.

This breaks plymouth installs, either because plymouth is using the file
"incorrectly" or because the patch is incorrect.  Either way, this needs
to be reverted until it is all figured out.

Reported-by: Josh Boyer 
Reported-by: Ray Strode 
Cc: Lennart Poettering 
Cc: Kay Sievers 
Cc: Jiri Slaby 
Cc: David Herrmann 
Cc: Werner Fink 
Cc: Hannes Reinecke 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman