1. 13 May, 2014 3 commits
    • Peter Hurley's avatar
      n_tty: Fix n_tty_write crash when echoing in raw mode · abb51007
      Peter Hurley authored
      commit 4291086b upstream.
      
      The tty atomic_write_lock does not provide an exclusion guarantee for
      the tty driver if the termios settings are LECHO & !OPOST.  And since
      it is unexpected and not allowed to call TTY buffer helpers like
      tty_insert_flip_string concurrently, this may lead to crashes when
      concurrect writers call pty_write. In that case the following two
      writers:
      * the ECHOing from a workqueue and
      * pty_write from the process
      race and can overflow the corresponding TTY buffer like follows.
      
      If we look into tty_insert_flip_string_fixed_flag, there is:
        int space = __tty_buffer_request_room(port, goal, flags);
        struct tty_buffer *tb = port->buf.tail;
        ...
        memcpy(char_buf_ptr(tb, tb->used), chars, space);
        ...
        tb->used += space;
      
      so the race of the two can result in something like this:
                    A                                B
      __tty_buffer_request_room
                                        __tty_buffer_request_room
      memcpy(buf(tb->used), ...)
      tb->used += space;
                                        memcpy(buf(tb->used), ...) ->BOOM
      
      B's memcpy is past the tty_buffer due to the previous A's tb->used
      increment.
      
      Since the N_TTY line discipline input processing can output
      concurrently with a tty write, obtain the N_TTY ldisc output_lock to
      serialize echo output with normal tty writes.  This ensures the tty
      buffer helper tty_insert_flip_string is not called concurrently and
      everything is fine.
      
      Note that this is nicely reproducible by an ordinary user using
      forkpty and some setup around that (raw termios + ECHO). And it is
      present in kernels at least after commit
      d945cb9c (pty: Rework the pty layer to
      use the normal buffering logic) in 2.6.31-rc3.
      
      js: add more info to the commit log
      js: switch to bool
      js: lock unconditionally
      js: lock only the tty->ops->write call
      
      References: CVE-2014-0196
      Reported-and-tested-by: default avatarJiri Slaby <jslaby@suse.cz>
      Signed-off-by: default avatarPeter Hurley <peter@hurleysoftware.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      abb51007
    • Michael Welling's avatar
      tty: serial: 8250_core.c Bug fix for Exar chips. · 437c7b9d
      Michael Welling authored
      commit b790f210 upstream.
      
      The sleep function was updated to put the serial port to sleep only when necessary.
      This appears to resolve the errant behavior of the driver as described in
      Kernel Bug 61961 – "My Exar Corp. XR17C/D152 Dual PCI UART modem does not
      work with 3.8.0".
      Signed-off-by: default avatarMichael Welling <mwelling@ieee.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      437c7b9d
    • Tomoki Sekiyama's avatar
      drivers/tty/hvc: don't free hvc_console_setup after init · eebf62b8
      Tomoki Sekiyama authored
      commit 501fed45 upstream.
      
      When 'console=hvc0' is specified to the kernel parameter in x86 KVM guest,
      hvc console is setup within a kthread. However, that will cause SEGV
      and the boot will fail when the driver is builtin to the kernel,
      because currently hvc_console_setup() is annotated with '__init'. This
      patch removes '__init' to boot the guest successfully with 'console=hvc0'.
      Signed-off-by: default avatarTomoki Sekiyama <tomoki.sekiyama@hds.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      eebf62b8
  2. 06 May, 2014 37 commits