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

tty: Fix unsafe ldisc reference via ioctl(TIOCGETD)

2016-02-17T20:34:38+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

tty: fix up atime/mtime mess, take four

2015-03-18T12:31:31+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: Greg Kroah-Hartman

tty: Fix high cpu load if tty is unreleaseable

2014-11-14T17:00:10+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

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

2014-04-27T00:19:04+00:00

commit 723abd87f6e536f1353c8f64f621520bc29523a3 upstream.

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: Jiri Slaby 
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

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

2014-02-07T16:40:54+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.

This resolves an issue on s390 platforms in determining the correct
console device to use.

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

tty: Reset hupped state on open

2013-11-25T16:56:49+00:00

A common security idiom is to hangup the current tty (via vhangup())
after forking but before execing a root shell. This hangs up any
existing opens which other processes may have and ensures subsequent
opens have the necessary permissions to open the root shell tty/pty.

Reset the TTY_HUPPED state after the driver has successfully
returned the opened tty (perform the reset while the tty is locked
to avoid racing with concurrent hangups).

Reported-by: Heorhi Valakhanovich 
Signed-off-by: Peter Hurley 
Cc: stable  # 3.12
Tested-by: Heorhi Valakhanovich 
Signed-off-by: Greg Kroah-Hartman

tty: disassociate_ctty() sends the extra SIGCONT

2013-09-18T01:53:32+00:00

Starting from v3.10 (probably commit f91e2590410b: "tty: Signal
foreground group processes in hangup") disassociate_ctty() sends SIGCONT
if tty && on_exit.  This breaks LSB test-suite, in particular test8 in
_exit.c and test40 in sigcon5.c.

Put the "!on_exit" check back to restore the old behaviour.

Review by Peter Hurley:
 "Yes, this regression was introduced by me in that commit.  The effect
  of the regression is that ptys will receive a SIGCONT when, in similar
  circumstances, ttys would not.

  The fact that two test vectors accidentally tripped over this
  regression suggests that some other apps may as well.

  Thanks for catching this"

Cc: stable@vger.kernel.org # v3.10+
Signed-off-by: Oleg Nesterov 
Reported-by: Karel Srot 
Reviewed-by: Peter Hurley 
Signed-off-by: Linus Torvalds

tty: Only hangup once

2013-08-02T03:47:42+00:00

Instrumented testing shows a tty can be hungup multiple times [1].
Although concurrent hangups are properly serialized, multiple
hangups for the same tty should be prevented.

If tty has already been HUPPED, abort hangup. Note it is not
necessary to cleanup file *redirect on subsequent hangups,
as only TIOCCONS can set that value and ioctls are disabled
after hangup.

[1]
Test performed by simulating a concurrent async hangup via
tty_hangup() with a sync hangup via tty_vhangup(), while
__tty_hangup() was instrumented with:

	diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
	index 26bb78c..fe8b061 100644
	--- a/drivers/tty/tty_io.c
	+++ b/drivers/tty/tty_io.c
	@@ -629,6 +629,8 @@ static void __tty_hangup(struct tty_struct *tty, int exit_session)

		tty_lock(tty);

	+	WARN_ON(test_bit(TTY_HUPPED, &tty->flags));
	+
		/* some functions below drop BTM, so we need this bit */
		set_bit(TTY_HUPPING, &tty->flags);

Test result:

WARNING: at /home/peter/src/kernels/mainline/drivers/tty/tty_io.c:632 __tty_hangup+0x459/0x460()
Modules linked in: ip6table_filter ip6_tables ebtable_nat <...snip...>
CPU: 6 PID: 1197 Comm: kworker/6:2 Not tainted 3.10.0-0+rfcomm-xeon #0+rfcomm
Hardware name: Dell Inc. Precision WorkStation T5400  /0RW203, BIOS A11 04/30/2012
Workqueue: events do_tty_hangup
 0000000000000009 ffff8802b16d7d18 ffffffff816b553e ffff8802b16d7d58
 ffffffff810407e0 ffff880254f95c00 ffff880254f95c00 ffff8802bfd92b00
 ffff8802bfd96b00 ffff880254f95e40 0000000000000180 ffff8802b16d7d68
Call Trace:
 [] dump_stack+0x19/0x1b
 [] warn_slowpath_common+0x70/0xa0
 [] warn_slowpath_null+0x1a/0x20
 [] __tty_hangup+0x459/0x460
 [] ? finish_task_switch+0xbc/0xe0
 [] do_tty_hangup+0x17/0x20
 [] process_one_work+0x16f/0x450
 [] process_scheduled_works+0x2c/0x40
 [] worker_thread+0x26a/0x380
 [] ? rescuer_thread+0x310/0x310
 [] kthread+0xc0/0xd0
 [] ? destroy_compound_page+0x65/0x92
 [] ? kthread_create_on_node+0x130/0x130
 [] ret_from_fork+0x7c/0xb0
 [] ? kthread_create_on_node+0x130/0x130
---[ end trace 98d9f01536cf411e ]---

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

tty: Fix lock order in tty_do_resize()

2013-07-24T22:12:53+00:00

Commits 6a1c0680cf3ba94356ecd58833e1540c93472a57 and
9356b535fcb71db494fc434acceb79f56d15bda2, respectively
  'tty: Convert termios_mutex to termios_rwsem' and
  'n_tty: Access termios values safely'
introduced a circular lock dependency with console_lock and
termios_rwsem.

The lockdep report [1] shows that n_tty_write() will attempt
to claim console_lock while holding the termios_rwsem, whereas
tty_do_resize() may already hold the console_lock while
claiming the termios_rwsem.

Since n_tty_write() and tty_do_resize() do not contend
over the same data -- the tty->winsize structure -- correct
the lock dependency by introducing a new lock which
specifically serializes access to tty->winsize only.

[1] Lockdep report

======================================================
[ INFO: possible circular locking dependency detected ]
3.10.0-0+tip-xeon+lockdep #0+tip Not tainted
-------------------------------------------------------
modprobe/277 is trying to acquire lock:
 (&tty->termios_rwsem){++++..}, at: [] tty_do_resize+0x36/0xe0

but task is already holding lock:
 ((fb_notifier_list).rwsem){.+.+.+}, at: [] __blocking_notifier_call_chain+0x56/0xc0

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #2 ((fb_notifier_list).rwsem){.+.+.+}:
       [] lock_acquire+0x92/0x1f0
       [] down_read+0x47/0x5c
       [] __blocking_notifier_call_chain+0x56/0xc0
       [] blocking_notifier_call_chain+0x16/0x20
       [] fb_notifier_call_chain+0x1b/0x20
       [] register_framebuffer+0x1e2/0x320
       [] drm_fb_helper_initial_config+0x371/0x540 [drm_kms_helper]
       [] nouveau_fbcon_init+0x105/0x140 [nouveau]
       [] nouveau_drm_load+0x43f/0x610 [nouveau]
       [] drm_get_pci_dev+0x17e/0x2a0 [drm]
       [] nouveau_drm_probe+0x25a/0x2a0 [nouveau]
       [] local_pci_probe+0x4b/0x80
       [] pci_device_probe+0x111/0x120
       [] driver_probe_device+0x8b/0x3a0
       [] __driver_attach+0xab/0xb0
       [] bus_for_each_dev+0x5d/0xa0
       [] driver_attach+0x1e/0x20
       [] bus_add_driver+0x111/0x290
       [] driver_register+0x77/0x170
       [] __pci_register_driver+0x64/0x70
       [] drm_pci_init+0x11a/0x130 [drm]
       [] nouveau_drm_init+0x4d/0x1000 [nouveau]
       [] do_one_initcall+0xea/0x1a0
       [] load_module+0x123b/0x1bf0
       [] SyS_init_module+0xd7/0x120
       [] system_call_fastpath+0x16/0x1b

-> #1 (console_lock){+.+.+.}:
       [] lock_acquire+0x92/0x1f0
       [] console_lock+0x77/0x80
       [] con_flush_chars+0x31/0x50
       [] n_tty_write+0x1ec/0x4d0
       [] tty_write+0x159/0x2e0
       [] redirected_tty_write+0xb5/0xc0
       [] vfs_write+0xc5/0x1f0
       [] SyS_write+0x55/0xa0
       [] system_call_fastpath+0x16/0x1b

-> #0 (&tty->termios_rwsem){++++..}:
       [] __lock_acquire+0x1c43/0x1d30
       [] lock_acquire+0x92/0x1f0
       [] down_write+0x44/0x70
       [] tty_do_resize+0x36/0xe0
       [] vc_do_resize+0x3e1/0x4c0
       [] vc_resize+0x1f/0x30
       [] fbcon_init+0x385/0x5a0
       [] visual_init+0xbc/0x120
       [] do_bind_con_driver+0x163/0x320
       [] do_take_over_console+0x61/0x70
       [] do_fbcon_takeover+0x63/0xc0
       [] fbcon_event_notify+0x715/0x820
       [] notifier_call_chain+0x5d/0x110
       [] __blocking_notifier_call_chain+0x6c/0xc0
       [] blocking_notifier_call_chain+0x16/0x20
       [] fb_notifier_call_chain+0x1b/0x20
       [] register_framebuffer+0x1e2/0x320
       [] drm_fb_helper_initial_config+0x371/0x540 [drm_kms_helper]
       [] nouveau_fbcon_init+0x105/0x140 [nouveau]
       [] nouveau_drm_load+0x43f/0x610 [nouveau]
       [] drm_get_pci_dev+0x17e/0x2a0 [drm]
       [] nouveau_drm_probe+0x25a/0x2a0 [nouveau]
       [] local_pci_probe+0x4b/0x80
       [] pci_device_probe+0x111/0x120
       [] driver_probe_device+0x8b/0x3a0
       [] __driver_attach+0xab/0xb0
       [] bus_for_each_dev+0x5d/0xa0
       [] driver_attach+0x1e/0x20
       [] bus_add_driver+0x111/0x290
       [] driver_register+0x77/0x170
       [] __pci_register_driver+0x64/0x70
       [] drm_pci_init+0x11a/0x130 [drm]
       [] nouveau_drm_init+0x4d/0x1000 [nouveau]
       [] do_one_initcall+0xea/0x1a0
       [] load_module+0x123b/0x1bf0
       [] SyS_init_module+0xd7/0x120
       [] system_call_fastpath+0x16/0x1b

other info that might help us debug this:

Chain exists of:
  &tty->termios_rwsem --> console_lock --> (fb_notifier_list).rwsem

 Possible unsafe locking scenario:

       CPU0                    CPU1
       ----                    ----
  lock((fb_notifier_list).rwsem);
                               lock(console_lock);
                               lock((fb_notifier_list).rwsem);
  lock(&tty->termios_rwsem);

 *** DEADLOCK ***

7 locks held by modprobe/277:
 #0:  (&__lockdep_no_validate__){......}, at: [] __driver_attach+0x5b/0xb0
 #1:  (&__lockdep_no_validate__){......}, at: [] __driver_attach+0x69/0xb0
 #2:  (drm_global_mutex){+.+.+.}, at: [] drm_get_pci_dev+0xbd/0x2a0 [drm]
 #3:  (registration_lock){+.+.+.}, at: [] register_framebuffer+0x25/0x320
 #4:  (&fb_info->lock){+.+.+.}, at: [] lock_fb_info+0x26/0x60
 #5:  (console_lock){+.+.+.}, at: [] register_framebuffer+0x1d4/0x320
 #6:  ((fb_notifier_list).rwsem){.+.+.+}, at: [] __blocking_notifier_call_chain+0x56/0xc0

stack backtrace:
CPU: 0 PID: 277 Comm: modprobe Not tainted 3.10.0-0+tip-xeon+lockdep #0+tip
Hardware name: Dell Inc. Precision WorkStation T5400  /0RW203, BIOS A11 04/30/2012
 ffffffff8213e5e0 ffff8802aa2fb298 ffffffff81755f19 ffff8802aa2fb2e8
 ffffffff8174f506 ffff8802aa2fa000 ffff8802aa2fb378 ffff8802aa2ea8e8
 ffff8802aa2ea910 ffff8802aa2ea8e8 0000000000000006 0000000000000007
Call Trace:
 [] dump_stack+0x19/0x1b
 [] print_circular_bug+0x1fb/0x20c
 [] __lock_acquire+0x1c43/0x1d30
 [] ? mark_held_locks+0xae/0x120
 [] ? trace_hardirqs_on_caller+0x105/0x1d0
 [] lock_acquire+0x92/0x1f0
 [] ? tty_do_resize+0x36/0xe0
 [] down_write+0x44/0x70
 [] ? tty_do_resize+0x36/0xe0
 [] tty_do_resize+0x36/0xe0
 [] vc_do_resize+0x3e1/0x4c0
 [] vc_resize+0x1f/0x30
 [] fbcon_init+0x385/0x5a0
 [] visual_init+0xbc/0x120
 [] do_bind_con_driver+0x163/0x320
 [] do_take_over_console+0x61/0x70
 [] do_fbcon_takeover+0x63/0xc0
 [] fbcon_event_notify+0x715/0x820
 [] notifier_call_chain+0x5d/0x110
 [] __blocking_notifier_call_chain+0x6c/0xc0
 [] blocking_notifier_call_chain+0x16/0x20
 [] fb_notifier_call_chain+0x1b/0x20
 [] register_framebuffer+0x1e2/0x320
 [] drm_fb_helper_initial_config+0x371/0x540 [drm_kms_helper]
 [] ? kmemleak_alloc+0x5b/0xc0
 [] ? kmem_cache_alloc_trace+0x104/0x290
 [] ? drm_fb_helper_single_add_all_connectors+0x81/0xf0 [drm_kms_helper]
 [] nouveau_fbcon_init+0x105/0x140 [nouveau]
 [] nouveau_drm_load+0x43f/0x610 [nouveau]
 [] drm_get_pci_dev+0x17e/0x2a0 [drm]
 [] nouveau_drm_probe+0x25a/0x2a0 [nouveau]
 [] ? _raw_spin_unlock_irqrestore+0x42/0x80
 [] local_pci_probe+0x4b/0x80
 [] pci_device_probe+0x111/0x120
 [] driver_probe_device+0x8b/0x3a0
 [] __driver_attach+0xab/0xb0
 [] ? driver_probe_device+0x3a0/0x3a0
 [] bus_for_each_dev+0x5d/0xa0
 [] driver_attach+0x1e/0x20
 [] bus_add_driver+0x111/0x290
 [] ? 0xffffffffa0229fff
 [] driver_register+0x77/0x170
 [] ? 0xffffffffa0229fff
 [] __pci_register_driver+0x64/0x70
 [] drm_pci_init+0x11a/0x130 [drm]
 [] ? 0xffffffffa0229fff
 [] ? 0xffffffffa0229fff
 [] nouveau_drm_init+0x4d/0x1000 [nouveau]
 [] do_one_initcall+0xea/0x1a0
 [] load_module+0x123b/0x1bf0
 [] ? ddebug_proc_open+0xb0/0xb0
 [] ? trace_hardirqs_on_thunk+0x3a/0x3f
 [] SyS_init_module+0xd7/0x120
 [] system_call_fastpath+0x16/0x1b

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