linux.git/drivers/tty, branch v3.14.41

n_tty: Fix read buffer overwrite when no newline

2015-04-19T08:11:08+00:00

commit fb5ef9e7da39968fec6d6f37f20a23d23740c75e upstream.

In canon mode, the read buffer head will advance over the buffer tail
if the input > 4095 bytes without receiving a line termination char.

Discard additional input until a line termination is received.
Before evaluating for overflow, the 'room' value is normalized for
I_PARMRK and 1 byte is reserved for line termination (even in !icanon
mode, in case the mode is switched). The following table shows the
transform:

 actual buffer |  'room' value before overflow calc
  space avail  |    !I_PARMRK    |    I_PARMRK
 --------------------------------------------------
      0        |       -1        |       -1
      1        |        0        |        0
      2        |        1        |        0
      3        |        2        |        0
      4+       |        3        |        1

When !icanon or when icanon and the read buffer contains newlines,
normalized 'room' values of -1 and 0 are clamped to 0, and
'overflow' is 0, so read_head is not adjusted and the input i/o loop
exits (setting no_room if called from flush_to_ldisc()). No input
is discarded since the reader does have input available to read
which ensures forward progress.

When icanon and the read buffer does not contain newlines and the
normalized 'room' value is 0, then overflow and room are reset to 1,
so that the i/o loop will process the next input char normally
(except for parity errors which are ignored). Thus, erasures, signalling
chars, 7-bit mode, etc. will continue to be handled properly.

If the input char processed was not a line termination char, then
the canon_head index will not have advanced, so the normalized 'room'
value will now be -1 and 'overflow' will be set, which indicates the
read_head can safely be reset, effectively erasing the last char
processed.

If the input char processed was a line termination, then the
canon_head index will have advanced, so 'overflow' is cleared to 0,
the read_head is not reset, and 'room' is cleared to 0, which exits
the i/o loop (because the reader now have input available to read
which ensures forward progress).

Note that it is possible for a line termination to be received, and
for the reader to copy the line to the user buffer before the
input i/o loop is ready to process the next input char. This is
why the i/o loop recomputes the room/overflow state with every
input char while handling overflow.

Finally, if the input data was processed without receiving
a line termination (so that overflow is still set), the pty
driver must receive a write wakeup. A pty writer may be waiting
to write more data in n_tty_write() but without unthrottling
here that wakeup will not arrive, and forward progress will halt.
(Normally, the pty writer is woken when the reader reads data out
of the buffer and more space become available).

Signed-off-by: Peter Hurley 
Signed-off-by: Greg Kroah-Hartman 
(backported from commit fb5ef9e7da39968fec6d6f37f20a23d23740c75e)
Signed-off-by: Joseph Salisbury

tty: serial: fsl_lpuart: clear receive flag on FIFO flush

2015-04-19T08:11:08+00:00

commit 8e4934c6d6c659e22b1b746af4196683e77ce6ca upstream.

When the receiver was enabled during startup, a character could
have been in the FIFO when the UART get initially used. The
driver configures the (receive) watermark level, and flushes the
FIFO. However, the receive flag (RDRF) could still be set at that
stage (as mentioned in the register description of UARTx_RWFIFO).
This leads to an interrupt which won't be handled properly in
interrupt mode: The receive interrupt function lpuart_rxint checks
the FIFO count, which is 0 at that point (due to the flush
during initialization). The problem does not manifest when using
DMA to receive characters.

Fix this situation by explicitly read the status register, which
leads to clearing of the RDRF flag. Due to the flush just after
the status flag read, a explicit data read is not to required.

Signed-off-by: Stefan Agner 
Signed-off-by: Greg Kroah-Hartman

Change email address for 8250_pci

2015-03-26T14:06:53+00:00

commit f2e0ea861117bda073d1d7ffbd3120c07c0d5d34 upstream.

I'm still receiving reports to my email address, so let's point this
at the linux-serial mailing list instead.

Signed-off-by: Russell King 
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 tty_wait_until_sent on 64-bit machines

2015-03-18T12:31:30+00:00

commit 79fbf4a550ed6a22e1ae1516113e6c7fa5d56a53 upstream.

Fix overflow bug in tty_wait_until_sent on 64-bit machines, where an
infinite timeout (0) would be passed to the underlying tty-driver's
wait_until_sent-operation as a negative timeout (-1), causing it to
return immediately.

This manifests itself for example as tcdrain() returning immediately,
drivers not honouring the drain flags when setting terminal attributes,
or even dropped data on close as a requested infinite closing-wait
timeout would be ignored.

The first symptom  was reported by Asier LLANO who noted that tcdrain()
returned prematurely when using the ftdi_sio usb-serial driver.

Fix this by passing 0 rather than MAX_SCHEDULE_TIMEOUT (LONG_MAX) to the
underlying tty driver.

Note that the serial-core wait_until_sent-implementation is not affected
by this bug due to a lucky chance (comparison to an unsigned maximum
timeout), and neither is the cyclades one that had an explicit check for
negative timeouts, but all other tty drivers appear to be affected.

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Reported-by: ZIV-Asier Llano Palacios 
Signed-off-by: Johan Hovold 
Reviewed-by: Peter Hurley 
Signed-off-by: Greg Kroah-Hartman

vt: provide notifications on selection changes

2015-03-06T22:43:30+00:00

commit 19e3ae6b4f07a87822c1c9e7ed99d31860e701af upstream.

The vcs device's poll/fasync support relies on the vt notifier to signal
changes to the screen content.  Notifier invocations were missing for
changes that comes through the selection interface though.  Fix that.

Tested with BRLTTY 5.2.

Signed-off-by: Nicolas Pitre 
Cc: Dave Mielke 
Signed-off-by: Greg Kroah-Hartman

tty/serial: at91: fix error handling in atmel_serial_probe()

2015-03-06T22:43:30+00:00

commit 6fbb9bdf0f3fbe23aeff806489791aa876adaffb upstream.

-EDEFER error wasn't handle properly by atmel_serial_probe().
As an example, when atmel_serial_probe() is called for the first time, we pass
the test_and_set_bit() test to check whether the port has already been
initalized. Then we call atmel_init_port(), which may return -EDEFER, possibly
returned before by clk_get(). Consequently atmel_serial_probe() used to return
this error code WITHOUT clearing the port bit in the "atmel_ports_in_use" mask.
When atmel_serial_probe() was called for the second time, it used to fail on
the test_and_set_bit() function then returning -EBUSY.

When atmel_serial_probe() fails, this patch make it clear the port bit in the
"atmel_ports_in_use" mask, if needed, before returning the error code.

Signed-off-by: Cyrille Pitchen 
Acked-by: Nicolas Ferre 
Signed-off-by: Greg Kroah-Hartman

tty: Prevent untrappable signals from malicious program

2015-03-06T22:43:30+00:00

commit 37480a05685ed5b8e1b9bf5e5c53b5810258b149 upstream.

Commit 26df6d13406d1a5 ("tty: Add EXTPROC support for LINEMODE")
allows a process which has opened a pty master to send _any_ signal
to the process group of the pty slave. Although potentially
exploitable by a malicious program running a setuid program on
a pty slave, it's unknown if this exploit currently exists.

Limit to signals actually used.

Cc: Theodore Ts'o 
Cc: Howard Chu 
Cc: One Thousand Gnomes 
Cc: Jiri Slaby 
Signed-off-by: Peter Hurley 
Signed-off-by: Greg Kroah-Hartman

tty: Fix pty master poll() after slave closes v2

2015-01-30T01:40:51+00:00

commit c4dc304677e8d566572c4738d95c48be150c6606 upstream.

Commit f95499c3030f ("n_tty: Don't wait for buffer work in read() loop")
introduces a race window where a pty master can be signalled that the pty
slave was closed before all the data that the slave wrote is delivered.
Commit f8747d4a466a ("tty: Fix pty master read() after slave closes") fixed the
problem in case of n_tty_read, but the problem still exists for n_tty_poll.
This can be seen by running 'for ((i=0; i<100;i++));do ./test.py ;done'
where test.py is:

import os, select, pty

(pid, pty_fd) = pty.fork()

if pid == 0:
   os.write(1, 'This string should be received by parent')
else:
   poller = select.epoll()
   poller.register( pty_fd, select.EPOLLIN )
   ready = poller.poll( 1 * 1000 )
   for fd, events in ready:
      if not events & select.EPOLLIN:
         print 'missed POLLIN event'
      else:
         print os.read(fd, 100)
   poller.close()

The string from the slave is missed several times.
This patch takes the same approach as the fix for read and special cases
this condition for poll.
Tested on 3.16.

Signed-off-by: Francesco Ruggeri 
Cc: Peter Hurley 
Signed-off-by: Greg Kroah-Hartman

n_tty: Fix read_buf race condition, increment read_head after pushing data

2015-01-16T14:59:32+00:00

commit 8bfbe2de769afda051c56aba5450391670e769fc upstream.

Commit 19e2ad6a09f0c06dbca19c98e5f4584269d913dd ("n_tty: Remove overflow
tests from receive_buf() path") moved the increment of read_head into
the arguments list of read_buf_addr(). Function calls represent a
sequence point in C. Therefore read_head is incremented before the
character c is placed in the buffer. Since the circular read buffer is
a lock-less design since commit 6d76bd2618535c581f1673047b8341fd291abc67
("n_tty: Make N_TTY ldisc receive path lockless"), this creates a race
condition that leads to communication errors.

This patch modifies the code to increment read_head _after_ the data
is placed in the buffer and thus fixes the race for non-SMP machines.
To fix the problem for SMP machines, memory barriers must be added in
a separate patch.

Signed-off-by: Christian Riesch 
Signed-off-by: Greg Kroah-Hartman