1. 12 8月, 2008 1 次提交
    • C
      Fix race/oops in tty layer after BKL pushdown · 000b9151
      Christian Borntraeger 提交于
      While testing our KVM code for s390 (starting and killall kvm in a loop)
      I can reproduce the following oops:
      
        Unable to handle kernel pointer dereference at virtual kernel address 6b6b6b6b6b6b6000 Oops: 0038 [#1] SMP
        Modules linked in: dm_multipath sunrpc qeth_l3 qeth_l2 dm_mod qeth
        ccwgroup CPU: 1 Not tainted 2.6.27-rc1 #54
        Process kuli (pid: 4409, task: 00000000b6aa5940, ksp: 00000000b7343e10)
        Krnl PSW : 0704e00180000000 00000000002e0b8c
        (disassociate_ctty+0x1c0/0x288) R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3
        CC:2 PM:0 EA:3 Krnl GPRS: 0000000000000000 6b6b6b6b6b6b6b6b
        0000000000000001 00000000000003a6 00000000002e0a46 00000000004b4160
        0000000000000001 00000000bbd79758 00000000b7343e58 00000000b8854148
        00000000bd34dea0 00000000b7343c20 0000000000000001 00000000004b6d08
        00000000002e0a46 00000000b7343c20 Krnl Code: 00000000002e0b7e:
        eb9fb0a00004	lmg	%r9,%r15,160(%r11) 00000000002e0b84:
        07f4		bcr	15,%r4 00000000002e0b86:
        e31090080004	lg	%r1,8(%r9) >00000000002e0b8c:
        d501109cd000	clc	156(2,%r1),0(%r13) 00000000002e0b92:
        a784ff5d		brc	8,2e0a4c 00000000002e0b96:
        b9040029		lgr	%r2,%r9 00000000002e0b9a:
        c0e5fffff9c3	brasl	%r14,2dff20 00000000002e0ba0:
        a7f4ff56		brc	15,2e0a4c Call Trace:
        ([<00000000002e0a46>] disassociate_ctty+0x7a/0x288)
         [<0000000000141fe6>] do_exit+0x212/0x8d4
         [<0000000000142708>] do_group_exit+0x60/0xcc
         [<0000000000150660>] get_signal_to_deliver+0x270/0x3ac
         [<000000000010bfd6>] do_signal+0x8e/0x8dc
         [<0000000000113772>] sysc_sigpending+0xe/0x22
         [<000001ff0000b134>] 0x1ff0000b134
        INFO: lockdep is turned off.
        Last Breaking-Event-Address:
         [<00000000002e0a48>] disassociate_ctty+0x7c/0x288
        Kernel panic - not syncing: Fatal exception: panic_on_oops
      
      It seems that tty was already free in disassocate_ctty when it tries
      to dereference tty->driver.
      
      After moving the lock_kernel before the mutex_unlock, I can no longer
      reproduce the problem.
      
      [ This is a temporary partial fix for the documented and long standing
        race in disassociate_tty.  This stops most problem cases for now.
      
        For the next release the -next tree has an initial implementation of
        kref counting for tty structures and this quickfix will be dropped.
      
                                                                    - Alan ]
      Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com>
      Signed-off-by; Alan Cox <alan@redhat.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      000b9151
  2. 26 7月, 2008 1 次提交
  3. 25 7月, 2008 1 次提交
  4. 23 7月, 2008 3 次提交
  5. 22 7月, 2008 1 次提交
  6. 21 7月, 2008 4 次提交
  7. 03 7月, 2008 2 次提交
  8. 21 6月, 2008 1 次提交
  9. 15 5月, 2008 1 次提交
    • A
      tty_check_change(): avoid taking tasklist_lock while holding tty->ctrl_lock · 9ffee4cb
      Andrew Morton 提交于
      May 11 09:42:27 [kernel] [ 1104.496819] rarian-sk-get-c[5630]: segfault at 0 ip 7f478556caf0 sp 7fff8e3fe338 error 4 in libc-2.6.1.so[7f47854f9000+136000]
      May 11 10:59:48 [kernel] [ 2494.165792]
      May 11 10:59:48 [kernel] [ 2494.165794] =======================================================
      May 11 10:59:48 [kernel] [ 2494.165801] [ INFO: possible circular locking dependency detected ]
      May 11 10:59:48 [kernel] [ 2494.165805] 2.6.26-rc1-00007-g91b3a7a #217
      May 11 10:59:48 [kernel] [ 2494.165807] -------------------------------------------------------
      May 11 10:59:48 [kernel] [ 2494.165809] less/7053 is trying to acquire lock:
      May 11 10:59:48 [kernel] [ 2494.165812]  (tasklist_lock){..??}, at: [<ffffffff80232e95>] is_current_pgrp_orphaned+0x15/0x50
      May 11 10:59:48 [kernel] [ 2494.165821]
      May 11 10:59:48 [kernel] [ 2494.165822] but task is already holding lock:
      May 11 10:59:48 [kernel] [ 2494.165824]  (&tty->ctrl_lock){....}, at: [<ffffffff803d5f31>] tty_check_change+0x61/0x110
      May 11 10:59:48 [kernel] [ 2494.165831]
      May 11 10:59:48 [kernel] [ 2494.165832] which lock already depends on the new lock.
      May 11 10:59:48 [kernel] [ 2494.165833]
      May 11 10:59:48 [kernel] [ 2494.165835]
      May 11 10:59:48 [kernel] [ 2494.165836] the existing dependency chain (in reverse order) is:
      May 11 10:59:48 [kernel] [ 2494.165838]
      May 11 10:59:48 [kernel] [ 2494.165839] -> #2 (&tty->ctrl_lock){....}:
      May 11 10:59:48 [kernel] [ 2494.165843]        [<ffffffff80253796>] __lock_acquire+0xf86/0x1080
      May 11 10:59:48 [kernel] [ 2494.165851]        [<ffffffff80253922>] lock_acquire+0x92/0xc0
      May 11 10:59:48 [kernel] [ 2494.165858]        [<ffffffff804deee0>] _spin_lock_irqsave+0x40/0x60
      May 11 10:59:48 [kernel] [ 2494.165866]        [<ffffffff803d31b5>] __proc_set_tty+0x35/0xe0
      May 11 10:59:48 [kernel] [ 2494.165873]        [<ffffffff803d76d4>] tty_ioctl+0xbf4/0xfe0
      May 11 10:59:48 [kernel] [ 2494.165880]        [<ffffffff802a05e1>] vfs_ioctl+0x31/0x90
      May 11 10:59:48 [kernel] [ 2494.165888]        [<ffffffff802a06b3>] do_vfs_ioctl+0x73/0x2d0
      May 11 10:59:48 [kernel] [ 2494.165895]        [<ffffffff802a095a>] sys_ioctl+0x4a/0x80
      May 11 10:59:48 [kernel] [ 2494.165902]        [<ffffffff8020b5ab>] system_call_after_swapgs+0x7b/0x80
      May 11 10:59:48 [kernel] [ 2494.165910]        [<ffffffffffffffff>] 0xffffffffffffffff
      May 11 10:59:48 [kernel] [ 2494.165924]
      May 11 10:59:48 [kernel] [ 2494.165925] -> #1 (&sighand->siglock){++..}:
      May 11 10:59:48 [kernel] [ 2494.165929]        [<ffffffff80253796>] __lock_acquire+0xf86/0x1080
      May 11 10:59:48 [kernel] [ 2494.165936]        [<ffffffff80253922>] lock_acquire+0x92/0xc0
      May 11 10:59:48 [kernel] [ 2494.165943]        [<ffffffff804dec1f>] _spin_lock+0x2f/0x40
      May 11 10:59:48 [kernel] [ 2494.165951]        [<ffffffff8022d5a3>] copy_process+0x973/0x1210
      May 11 10:59:48 [kernel] [ 2494.165959]        [<ffffffff8022df12>] do_fork+0x82/0x2f0
      May 11 10:59:48 [kernel] [ 2494.165967]        [<ffffffff8020bfe1>] kernel_thread+0x81/0xde
      May 11 10:59:48 [kernel] [ 2494.165974]        [<ffffffff8020c048>] child_rip+0xa/0x12
      May 11 10:59:48 [kernel] [ 2494.165981]        [<ffffffffffffffff>] 0xffffffffffffffff
      May 11 10:59:48 [kernel] [ 2494.166038]
      May 11 10:59:48 [kernel] [ 2494.166039] -> #0 (tasklist_lock){..??}:
      May 11 10:59:48 [kernel] [ 2494.166043]        [<ffffffff802535ab>] __lock_acquire+0xd9b/0x1080
      May 11 10:59:48 [kernel] [ 2494.166050]        [<ffffffff80253922>] lock_acquire+0x92/0xc0
      May 11 10:59:48 [kernel] [ 2494.166057]        [<ffffffff804dede2>] _read_lock+0x32/0x50
      May 11 10:59:48 [kernel] [ 2494.166063]        [<ffffffff80232e95>] is_current_pgrp_orphaned+0x15/0x50
      May 11 10:59:48 [kernel] [ 2494.166071]        [<ffffffff803d5f80>] tty_check_change+0xb0/0x110
      May 11 10:59:48 [kernel] [ 2494.166078]        [<ffffffff803dac5f>] set_termios+0x1f/0x4c0
      May 11 10:59:48 [kernel] [ 2494.166085]        [<ffffffff803db379>] tty_mode_ioctl+0x279/0x3e0
      May 11 10:59:48 [kernel] [ 2494.166092]        [<ffffffff803db51d>] n_tty_ioctl+0x3d/0x260
      May 11 10:59:48 [kernel] [ 2494.166100]        [<ffffffff803d6c34>] tty_ioctl+0x154/0xfe0
      May 11 10:59:48 [kernel] [ 2494.166107]        [<ffffffff802a05e1>] vfs_ioctl+0x31/0x90
      May 11 10:59:48 [kernel] [ 2494.166114]        [<ffffffff802a06b3>] do_vfs_ioctl+0x73/0x2d0
      May 11 10:59:48 [kernel] [ 2494.166121]        [<ffffffff802a095a>] sys_ioctl+0x4a/0x80
      May 11 10:59:48 [kernel] [ 2494.166128]        [<ffffffff8020b5ab>] system_call_after_swapgs+0x7b/0x80
      May 11 10:59:48 [kernel] [ 2494.166135]        [<ffffffffffffffff>] 0xffffffffffffffff
      May 11 10:59:48 [kernel] [ 2494.166142]
      May 11 10:59:48 [kernel] [ 2494.166143] other info that might help us debug this:
      May 11 10:59:48 [kernel] [ 2494.166144]
      May 11 10:59:48 [kernel] [ 2494.166146] 1 lock held by less/7053:
      May 11 10:59:48 [kernel] [ 2494.166148]  #0:  (&tty->ctrl_lock){....}, at: [<ffffffff803d5f31>] tty_check_change+0x61/0x110
      May 11 10:59:48 [kernel] [ 2494.166155]
      May 11 10:59:48 [kernel] [ 2494.166156] stack backtrace:
      May 11 10:59:48 [kernel] [ 2494.166159] Pid: 7053, comm: less Not tainted 2.6.26-rc1-00007-g91b3a7a #217
      May 11 10:59:48 [kernel] [ 2494.166161]
      May 11 10:59:48 [kernel] [ 2494.166162] Call Trace:
      May 11 10:59:48 [kernel] [ 2494.166168]  [<ffffffff80251223>] print_circular_bug_tail+0x83/0x90
      May 11 10:59:48 [kernel] [ 2494.166172]  [<ffffffff80250889>] ? print_circular_bug_entry+0x49/0x60
      May 11 10:59:48 [kernel] [ 2494.166178]  [<ffffffff802535ab>] __lock_acquire+0xd9b/0x1080
      May 11 10:59:48 [kernel] [ 2494.166184]  [<ffffffff80232e95>] ? is_current_pgrp_orphaned+0x15/0x50
      May 11 10:59:48 [kernel] [ 2494.166189]  [<ffffffff80253922>] lock_acquire+0x92/0xc0
      May 11 10:59:48 [kernel] [ 2494.166206]  [<ffffffff803d5f80>] tty_check_change+0xb0/0x110
      May 11 10:59:48 [kernel] [ 2494.166211]  [<ffffffff803dac5f>] set_termios+0x1f/0x4c0
      May 11 10:59:48 [kernel] [ 2494.166216]  [<ffffffff803d3423>] ? tty_ldisc_try+0x23/0x60
      May 11 10:59:48 [kernel] [ 2494.166220]  [<ffffffff803d3444>] ? tty_ldisc_try+0x44/0x60
      May 11 10:59:48 [kernel] [ 2494.166224]  [<ffffffff804df2c5>] ? _spin_unlock_irqrestore+0x65/0x80
      May 11 10:59:48 [kernel] [ 2494.166230]  [<ffffffff803db379>] tty_mode_ioctl+0x279/0x3e0
      May 11 10:59:48 [kernel] [ 2494.166234]  [<ffffffff803d3444>] ? tty_ldisc_try+0x44/0x60
      May 11 10:59:48 [kernel] [ 2494.166239]  [<ffffffff803db51d>] n_tty_ioctl+0x3d/0x260
      May 11 10:59:48 [kernel] [ 2494.166244]  [<ffffffff803d6c34>] tty_ioctl+0x154/0xfe0
      May 11 10:59:48 [kernel] [ 2494.166249]  [<ffffffff80252baa>] ? __lock_acquire+0x39a/0x1080
      May 11 10:59:48 [kernel] [ 2494.166256]  [<ffffffff80252baa>] ? __lock_acquire+0x39a/0x1080
      May 11 10:59:48 [kernel] [ 2494.166263]  [<ffffffff80252baa>] ? __lock_acquire+0x39a/0x1080
      May 11 10:59:48 [kernel] [ 2494.166269]  [<ffffffff802a05e1>] vfs_ioctl+0x31/0x90
      May 11 10:59:48 [kernel] [ 2494.166274]  [<ffffffff802a06b3>] do_vfs_ioctl+0x73/0x2d0
      May 11 10:59:48 [kernel] [ 2494.166280]  [<ffffffff802a095a>] sys_ioctl+0x4a/0x80
      May 11 10:59:48 [kernel] [ 2494.166286]  [<ffffffff8020b5ab>] system_call_after_swapgs+0x7b/0x80
      May 11 10:59:48 [kernel] [ 2494.166292]
      Acked-by: NAlan Cox <alan@lxorguk.ukuu.org.uk>
      Reported-by: NMarcin Slusarz <marcin.slusarz@gmail.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      9ffee4cb
  10. 02 5月, 2008 1 次提交
  11. 30 4月, 2008 9 次提交
  12. 29 4月, 2008 1 次提交
  13. 28 4月, 2008 1 次提交
    • M
      [patch 1/2] audit: let userspace fully control TTY input auditing · 41126226
      Miloslav Trmac 提交于
      Remove the code that automatically disables TTY input auditing in processes
      that open TTYs when they have no other TTY open; this heuristic was
      intended to automatically handle daemons, but it has false positives (e.g.
      with sshd) that make it impossible to control TTY input auditing from a PAM
      module.  With this patch, TTY input auditing is controlled from user-space
      only.
      
      On the other hand, not even for daemons does it make sense to audit "input"
      from PTY masters; this data was produced by a program writing to the PTY
      slave, and does not represent data entered by the user.
      Signed-off-by: NMiloslav Trmac <mitr@redhat.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: David Woodhouse <dwmw2@infradead.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      41126226
  14. 18 4月, 2008 1 次提交
  15. 09 2月, 2008 1 次提交
  16. 07 2月, 2008 3 次提交
  17. 20 10月, 2007 4 次提交
  18. 24 8月, 2007 1 次提交
  19. 12 8月, 2007 1 次提交
    • A
      fix serial buffer memory leak · 42fd552e
      Alan Cox 提交于
      Patch c5c34d48 (tty: flush flip buffer on
      ldisc input queue flush) introduces a race condition which can lead to memory
      leaks.
      
      The problem can be triggered when tcflush() is called when data are being
      pushed to the line discipline driver by flush_to_ldisc().
      
      flush_to_ldisc() releases tty->buf.lock when calling the line discipline
      receive_buf function. At that poing tty_buffer_flush() kicks in and sets both
      tty->buf.head and tty->buf.tail to NULL. When flush_to_ldisc() finishes, it
      restores tty->buf.head but doesn't touch tty->buf.tail. This corrups the
      buffer queue, and the next call to tty_buffer_request_room() will allocate a
      new buffer and overwrite tty->buf.head. The previous buffer is then lost
      forever without being released.
      
      (Thanks to Laurent for the above text, for finding, disgnosing and reporting
      the bug)
      
      - Use tty->flags bits for the flush status.
      
      - Wait for the flag to clear again before returning
      
      - Fix the doc error noted
      
      - Fix flush of empty queue leaving stale flushpending
      
      [akpm@linux-foundation.org: cleanup]
      Signed-off-by: NAlan Cox <alan@redhat.com>
      Acked-by: NPaul Fulghum <paulkf@microgate.com>
      Cc: Laurent Pinchart <laurentp@cse-semaphore.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      42fd552e
  20. 17 7月, 2007 2 次提交
    • M
      Audit: add TTY input auditing · 522ed776
      Miloslav Trmac 提交于
      Add TTY input auditing, used to audit system administrator's actions.  This is
      required by various security standards such as DCID 6/3 and PCI to provide
      non-repudiation of administrator's actions and to allow a review of past
      actions if the administrator seems to overstep their duties or if the system
      becomes misconfigured for unknown reasons.  These requirements do not make it
      necessary to audit TTY output as well.
      
      Compared to an user-space keylogger, this approach records TTY input using the
      audit subsystem, correlated with other audit events, and it is completely
      transparent to the user-space application (e.g.  the console ioctls still
      work).
      
      TTY input auditing works on a higher level than auditing all system calls
      within the session, which would produce an overwhelming amount of mostly
      useless audit events.
      
      Add an "audit_tty" attribute, inherited across fork ().  Data read from TTYs
      by process with the attribute is sent to the audit subsystem by the kernel.
      The audit netlink interface is extended to allow modifying the audit_tty
      attribute, and to allow sending explanatory audit events from user-space (for
      example, a shell might send an event containing the final command, after the
      interactive command-line editing and history expansion is performed, which
      might be difficult to decipher from the TTY input alone).
      
      Because the "audit_tty" attribute is inherited across fork (), it would be set
      e.g.  for sshd restarted within an audited session.  To prevent this, the
      audit_tty attribute is cleared when a process with no open TTY file
      descriptors (e.g.  after daemon startup) opens a TTY.
      
      See https://www.redhat.com/archives/linux-audit/2007-June/msg00000.html for a
      more detailed rationale document for an older version of this patch.
      
      [akpm@linux-foundation.org: build fix]
      Signed-off-by: NMiloslav Trmac <mitr@redhat.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
      Cc: Paul Fulghum <paulkf@microgate.com>
      Cc: Casey Schaufler <casey@schaufler-ca.com>
      Cc: Steve Grubb <sgrubb@redhat.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      522ed776
    • J
      tty_io: Use kzalloc · 506eb99a
      Jean Delvare 提交于
      Also remove needless casts.
      Signed-off-by: NJean Delvare <khali@linux-fr.org>
      Acked-by: NAlan Cox <alan@redhat.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      506eb99a