linux/drivers/tty, branch v3.12.24

serial: 8250_dw: Fix LCR workaround regression

2014-07-02T10:05:41Z

commit 6979f8d28049879e6147767d93ba6732c8bd94f4 upstream. Commit c49436b657d0 (serial: 8250_dw: Improve unwritable LCR workaround) caused a regression. It added a check that the LCR was written properly to detect and workaround the busy quirk, but the behaviour of bit 5 (UART_LCR_SPAR) differs between IP versions 3.00a and 3.14c per the docs. On older versions this caused the check to fail and it would repeatedly force idle and rewrite the LCR register, causing delays and preventing any input from serial being received. This is fixed by masking out UART_LCR_SPAR before making the comparison. Signed-off-by: James Hogan Cc: Greg Kroah-Hartman Cc: Jiri Slaby Cc: Tim Kryger Cc: Ezequiel Garcia Cc: Matt Porter Cc: Markus Mayer Tested-by: Tim Kryger Tested-by: Ezequiel Garcia Tested-by: Heikki Krogerus Signed-off-by: Greg Kroah-Hartman Signed-off-by: Jiri Slaby

serial: 8250_dw: Improve unwritable LCR workaround

2014-07-02T10:05:41Z

commit c49436b657d0a56a6ad90d14a7c3041add7cf64d upstream. When configured with UART_16550_COMPATIBLE=NO or in versions prior to the introduction of this option, the Designware UART will ignore writes to the LCR if the UART is busy. The current workaround saves a copy of the last written LCR and re-writes it in the ISR for a special interrupt that is raised when a write was ignored. Unfortunately, interrupts are typically disabled prior to performing a sequence of register writes that include the LCR so the point at which the retry occurs is too late. An example is serial8250_do_set_termios() where an ignored LCR write results in the baud divisor not being set and instead a garbage character is sent out the transmitter. Furthermore, since serial_port_out() offers no way to indicate failure, a serious effort must be made to ensure that the LCR is actually updated before returning back to the caller. This is difficult, however, as a UART that was busy during the first attempt is likely to still be busy when a subsequent attempt is made unless some extra action is taken. This updated workaround reads back the LCR after each write to confirm that the new value was accepted by the hardware. Should the hardware ignore a write, the TX/RX FIFOs are cleared and the receive buffer read before attempting to rewrite the LCR out of the hope that doing so will force the UART into an idle state. While this may seem unnecessarily aggressive, writes to the LCR are used to change the baud rate, parity, stop bit, or data length so the data that may be lost is likely not important. Admittedly, this is far from ideal but it seems to be the best that can be done given the hardware limitations. Lastly, the revised workaround doesn't touch the LCR in the ISR, so it avoids the possibility of a "serial8250: too much work for irq" lock up. This problem is rare in real situations but can be reproduced easily by wiring up two UARTs and running the following commands. # stty -F /dev/ttyS1 echo # stty -F /dev/ttyS2 echo # cat /dev/ttyS1 & [1] 375 # echo asdf > /dev/ttyS1 asdf [ 27.700000] serial8250: too much work for irq96 [ 27.700000] serial8250: too much work for irq96 [ 27.710000] serial8250: too much work for irq96 [ 27.710000] serial8250: too much work for irq96 [ 27.720000] serial8250: too much work for irq96 [ 27.720000] serial8250: too much work for irq96 [ 27.730000] serial8250: too much work for irq96 [ 27.730000] serial8250: too much work for irq96 [ 27.740000] serial8250: too much work for irq96 Signed-off-by: Tim Kryger Reviewed-by: Matt Porter Reviewed-by: Markus Mayer Reviewed-by: Heikki Krogerus Signed-off-by: Greg Kroah-Hartman Signed-off-by: Jiri Slaby Conflicts: drivers/tty/serial/8250/8250_dw.c

Staging: speakup: Update __speakup_paste_selection() tty (ab)usage to match vt

2014-06-20T15:34:05Z

commit 28a821c306889b9f2c3fff49abedc9b2c743eb73 upstream. This function is largely a duplicate of paste_selection() in drivers/tty/vt/selection.c, but with its own selection state. The speakup selection mechanism should really be merged with vt. For now, apply the changes from 'TTY: vt, fix paste_selection ldisc handling', 'tty: Make ldisc input flow control concurrency-friendly', and 'tty: Fix unsafe vt paste_selection()'. References: https://bugs.debian.org/735202 References: https://bugs.debian.org/744015 Reported-by: Paul Gevers Reported-and-tested-by: Jarek Czekalski Signed-off-by: Ben Hutchings Signed-off-by: Jiri Slaby

8250_core: Fix unwanted TX chars write

2014-06-06T09:40:21Z

commit b08c9c317e3f7764a91d522cd031639ba42b98cc upstream. On transmit-hold-register empty, serial8250_tx_chars should be called only if we don't use DMA. DMA has its own tx cycle. Signed-off-by: Loic Poulain Reviewed-by: Heikki Krogerus Signed-off-by: Jiri Slaby

serial: 8250: Fix thread unsafe __dma_tx_complete function

2014-06-06T09:40:21Z

commit f8fd1b0350d3a4581125f5eda6528f5a2c5f9183 upstream. __dma_tx_complete is not protected against concurrent call of serial8250_tx_dma. it can lead to circular tail index corruption or parallel call of serial_tx_dma on the same data portion. This patch fixes this issue by holding the port lock. Signed-off-by: Loic Poulain Reviewed-by: Heikki Krogerus Signed-off-by: Jiri Slaby

n_tty: Fix n_tty_write crash when echoing in raw mode

2014-05-15T07:55:48Z

commit 4291086b1f081b869c6d79e5b7441633dc3ace00 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 d945cb9cce20ac7143c2de8d88b187f62db99bdc (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: Jiri Slaby Signed-off-by: Peter Hurley Signed-off-by: Jiri Slaby Cc: Linus Torvalds Cc: Alan Cox Signed-off-by: Jiri Slaby

tty: Fix lockless tty buffer race

2014-05-15T07:55:47Z

commit 62a0d8d7c2b29f92850e4ee3c38e5dfd936e92b2 upstream. Commit 6a20dbd6caa2358716136144bf524331d70b1e03, "tty: Fix race condition between __tty_buffer_request_room and flush_to_ldisc" correctly identifies an unsafe race condition between __tty_buffer_request_room() and flush_to_ldisc(), where the consumer flush_to_ldisc() prematurely advances the head before consuming the last of the data committed. For example: CPU 0 | CPU 1 __tty_buffer_request_room | flush_to_ldisc ... | ... | count = head->commit - head->read n = tty_buffer_alloc() | b->commit = b->used | b->next = n | | if (!count) /* T */ | if (head->next == NULL) /* F */ | buf->head = head->next In this case, buf->head has been advanced but head->commit may have been updated with a new value. Instead of reintroducing an unnecessary lock, fix the race locklessly. Read the commit-next pair in the reverse order of writing, which guarantees the commit value read is the latest value written if the head is advancing. Reported-by: Manfred Schlaegl Signed-off-by: Peter Hurley Signed-off-by: Jiri Slaby

tty: serial: 8250_core.c Bug fix for Exar chips.

2014-05-15T07:55:46Z

commit b790f210fe8423eff881b2a8a93ba5dbc45534d0 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: Michael Welling Signed-off-by: Jiri Slaby

drivers/tty/hvc: don't free hvc_console_setup after init

2014-05-15T07:55:46Z

commit 501fed45b7e8836ee9373f4d31e2d85e3db6103a 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: Tomoki Sekiyama Signed-off-by: Jiri Slaby

hvc: ensure hvc_init is only ever called once in hvc_console.c

2014-05-15T07:55:33Z

commit f76a1cbed18c86e2d192455f0daebb48458965f3 upstream. Commit 3e6c6f630a5282df8f3393a59f10eb9c56536d23 ("Delay creation of khcvd thread") moved the call of hvc_init from being a device_initcall into hvc_alloc, and used a non-null hvc_driver as indication of whether hvc_init had already been called. The problem with this is that hvc_driver is only assigned a value at the bottom of hvc_init, and so there is a window where multiple hvc_alloc calls can be in progress at the same time and hence try and call hvc_init multiple times. Previously the use of device_init guaranteed that hvc_init was only called once. This manifests itself as sporadic instances of two hvc_init calls racing each other, and with the loser of the race getting -EBUSY from tty_register_driver() and hence that virtual console fails: Couldn't register hvc console driver virtio-ports vport0p1: error -16 allocating hvc for port Here we add an atomic_t to guarantee we'll never run hvc_init twice. Cc: Rusty Russell Cc: Greg Kroah-Hartman Fixes: 3e6c6f630a52 ("Delay creation of khcvd thread") Reported-by: Jim Somerville Tested-by: Jim Somerville Signed-off-by: Paul Gortmaker Signed-off-by: Jiri Slaby