linux-stable.git/drivers/tty, branch v3.10.99

pty: make sure super_block is still valid in final /dev/tty close

2016-02-25T19:57:46+00:00

commit 1f55c718c290616889c04946864a13ef30f64929 upstream.

Considering current pty code and multiple devpts instances, it's possible
to umount a devpts file system while a program still has /dev/tty opened
pointing to a previosuly closed pty pair in that instance. In the case all
ptmx and pts/N files are closed, umount can be done. If the program closes
/dev/tty after umount is done, devpts_kill_index will use now an invalid
super_block, which was already destroyed in the umount operation after
running ->kill_sb. This is another "use after free" type of issue, but now
related to the allocated super_block instance.

To avoid the problem (warning at ida_remove and potential crashes) for
this specific case, I added two functions in devpts which grabs additional
references to the super_block, which pty code now uses so it makes sure
the super block structure is still valid until pty shutdown is done.
I also moved the additional inode references to the same functions, which
also covered similar case with inode being freed before /dev/tty final
close/shutdown.

Signed-off-by: Herton R. Krzesinski 
Reviewed-by: Peter Hurley 
Signed-off-by: Greg Kroah-Hartman

pty: fix possible use after free of tty->driver_data

2016-02-25T19:57:46+00:00

commit 2831c89f42dcde440cfdccb9fee9f42d54bbc1ef upstream.

This change fixes a bug for a corner case where we have the the last
release from a pty master/slave coming from a previously opened /dev/tty
file. When this happens, the tty->driver_data can be stale, due to all
ptmx or pts/N files having already been closed before (and thus the inode
related to these files, which tty->driver_data points to, being already
freed/destroyed).

The fix here is to keep a reference on the opened master ptmx inode.
We maintain the inode referenced until the final pty_unix98_shutdown,
and only pass this inode to devpts_kill_index.

Signed-off-by: Herton R. Krzesinski 
Reviewed-by: Peter Hurley 
Signed-off-by: Greg Kroah-Hartman

tty: Fix unsafe ldisc reference via ioctl(TIOCGETD)

2016-02-19T22:22:41+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

serial: 8250: don't bind to SMSC IrCC IR port

2015-09-21T17:00:08+00:00

commit ffa34de03bcfbfa88d8352942bc238bb48e94e2d upstream.

SMSC IrCC SIR/FIR port should not be bound to by
(legacy) serial driver so its own driver (smsc-ircc2)
can bind to it.

Signed-off-by: Maciej Szmigiero 
Signed-off-by: Greg Kroah-Hartman

xen/console: Update console event channel on resume

2015-05-17T16:51:32+00:00

commit b9d934f27c91b878c4b2e64299d6e419a4022f8d upstream.

After a resume the hypervisor/tools may change console event
channel number. We should re-query it.

Signed-off-by: Boris Ostrovsky 
Signed-off-by: David Vrabel 
Signed-off-by: Greg Kroah-Hartman

serial: of-serial: Remove device_type = "serial" registration

2015-05-13T12:15:41+00:00

commit 6befa9d883385c580369a2cc9e53fbf329771f6d upstream.

Do not probe all serial drivers by of_serial.c which are using
device_type = "serial"; property. Only drivers which have valid
compatible strings listed in the driver should be probed.

When PORT_UNKNOWN is setup probe will fail anyway.

Arnd quotation about driver historical background:
"when I wrote that driver initially, the idea was that it would
get used as a stub to hook up all other serial drivers but after
that, the common code learned to create platform devices from DT"

This patch fix the problem with on the system with xilinx_uartps and
16550a where of_serial failed to register for xilinx_uartps and because
of irq_dispose_mapping() removed irq_desc. Then when xilinx_uartps was asking
for irq with request_irq() EINVAL is returned.

Signed-off-by: Michal Simek 
Acked-by: Arnd Bergmann 
Signed-off-by: Greg Kroah-Hartman

serial: 8250_dw: Fix deadlock in LCR workaround

2015-04-29T08:33:57+00:00

commit 7fd6f640f2dd17dac6ddd6702c378cb0bb9cfa11 upstream.

Trying to write console output from within the serial console driver
while the port->lock is held causes recursive deadlock:

  CPU 0
spin_lock_irqsave(&port->lock)
printk()
  console_unlock()
    call_console_drivers()
      serial8250_console_write()
        spin_lock_irqsave(&port->lock)
** DEADLOCK **

The 8250_dw i/o accessors try to write a console error message if the
LCR workaround was unsuccessful. When the port->lock is already held
(eg., when called from serial8250_set_termios()), this deadlocks.

Make the error message a FIXME until a general solution is devised.

Cc: Tim Kryger 
Reported-by: Zhang Zhen 
Signed-off-by: Peter Hurley 
Signed-off-by: Greg Kroah-Hartman

Change email address for 8250_pci

2015-03-26T14:00:58+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:22:33+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:22:31+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