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

drivers/tty: require read access for controlling terminal

2016-04-27T10:55:26+00:00

commit 0c55627167870255158db1cde0d28366f91c8872 upstream.

This is mostly a hardening fix, given that write-only access to other
users' ttys is usually only given through setgid tty executables.

Signed-off-by: Jann Horn 
Signed-off-by: Greg Kroah-Hartman 
[lizf: Backported to 3.4: adjust context]
Signed-off-by: Zefan Li

tty: fix up atime/mtime mess, take four

2015-06-19T03:40:22+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: Zefan Li

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

2015-02-02T09:05:15+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 
[lizf: Backported to 3.4: adjust context]
Signed-off-by: Zefan Li

tty: Fix high cpu load if tty is unreleaseable

2015-02-02T09:05:15+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: Zefan Li

tty: fix up atime/mtime mess, take three

2013-05-08T02:51:53+00:00

commit b0b885657b6c8ef63a46bc9299b2a7715d19acde upstream.

We first tried to avoid updating atime/mtime entirely (commit
b0de59b5733d: "TTY: do not update atime/mtime on read/write"), and then
limited it to only update it occasionally (commit 37b7f3c76595: "TTY:
fix atime/mtime regression"), but it turns out that this was both
insufficient and overkill.

It was insufficient because we let people attach to the shared ptmx node
to see activity without even reading atime/mtime, and it was overkill
because the "only once a minute" means that you can't really tell an
idle person from an active one with 'w'.

So this tries to fix the problem properly.  It marks the shared ptmx
node as un-notifiable, and it lowers the "only once a minute" to a few
seconds instead - still long enough that you can't time individual
keystrokes, but short enough that you can tell whether somebody is
active or not.

Reported-by: Simon Kirby 
Acked-by: Jiri Slaby 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

TTY: fix atime/mtime regression

2013-05-01T16:41:03+00:00

commit 37b7f3c76595e23257f61bd80b223de8658617ee upstream.

In commit b0de59b5733d ("TTY: do not update atime/mtime on read/write")
we removed timestamps from tty inodes to fix a security issue and waited
if something breaks.  Well, 'w', the utility to find out logged users
and their inactivity time broke.  It shows that users are inactive since
the time they logged in.

To revert to the old behaviour while still preventing attackers to
guess the password length, we update the timestamps in one-minute
intervals by this patch.

Signed-off-by: Jiri Slaby 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

TTY: do not update atime/mtime on read/write

2013-05-01T16:41:03+00:00

commit b0de59b5733d18b0d1974a060860a8b5c1b36a2e upstream.

On http://vladz.devzero.fr/013_ptmx-timing.php, we can see how to find
out length of a password using timestamps of /dev/ptmx. It is
documented in "Timing Analysis of Keystrokes and Timing Attacks on
SSH". To avoid that problem, do not update time when reading
from/writing to a TTY.

I am afraid of regressions as this is a behavior we have since 0.97
and apps may expect the time to be current, e.g. for monitoring
whether there was a change on the TTY. Now, there is no change. So
this would better have a lot of testing before it goes upstream.

References: CVE-2013-0160

Signed-off-by: Jiri Slaby 
Signed-off-by: Greg Kroah-Hartman

Remove all #inclusions of asm/system.h

2012-03-28T17:30:03+00:00

Remove all #inclusions of asm/system.h preparatory to splitting and killing
it.  Performed with the following command:

perl -p -i -e 's!^#\s*include\s*.*\n!!' `grep -Irl '^#\s*include\s*' *`

Signed-off-by: David Howells

TTY: remove tty driver re-set from tty_reopen

2012-03-08T19:38:50+00:00

This is from tty_reopen:
    struct tty_driver *driver = tty->driver;
    ...
    tty->driver = driver;
and it doesn't make sense at all. The driver is intended to be set in
initialize_tty_struct from tty_init_dev (initial open). So this set in
tty_reopen is not needed.

Signed-off-by: Jiri Slaby 
Signed-off-by: Greg Kroah-Hartman

TTY: simplify tty_driver_lookup_tty a bit

2012-03-08T19:38:50+00:00

Remove the useless local variable and return the value itself.

Signed-off-by: Jiri Slaby 
Signed-off-by: Greg Kroah-Hartman