user/sven/linux.git/drivers/tty, branch v3.18.28

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

2016-03-02T20:19:16Z

[ Upstream commit 1f55c718c290616889c04946864a13ef30f64929 ] 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 Cc: stable@vger.kernel.org # 2.6.29+ Reviewed-by: Peter Hurley Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

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

2016-03-02T20:19:15Z

[ Upstream commit 2831c89f42dcde440cfdccb9fee9f42d54bbc1ef ] 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 Cc: # 2.6.29+ Reviewed-by: Peter Hurley Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

tty: Add support for PCIe WCH382 2S multi-IO card

2016-03-02T20:19:13Z

[ Upstream commit 7dde55787b43a8f2b4021916db38d90c03a2ec64 ] WCH382 2S board is a PCIe card with 2 DB9 COM ports detected as Serial controller: Device 1c00:3253 (rev 10) (prog-if 05 [16850]) Signed-off-by: Jeremy McNicoll Cc: stable Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

tty: Add support for the WCH384 4S multi-IO card

2016-03-02T20:19:08Z

[ Upstream commit 72a3c0e4e6624a77ee6eee0903f209185fe20647 ] WCH384 4S board is a PCI-E card with 4 DB9 COM ports detected as Serial controller: Device 1c00:3470 (rev 10) (prog-if 05 [16850]) Signed-off-by: Sergej Pupykin Acked-by: Zany Yan Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

parport: Add support for the WCH382 2S/1P multi-IO card

2016-03-02T20:19:08Z

[ Upstream commit 2fdd8c8c5304901fa7dbb2ce5dbc90a1984cee3d ] WCH382 is a PCI-E card with 1 LPT and 2 DB9 COM ports detected as Serial controller: Device 1c00:3250 (rev 10) (prog-if 05 [16850]) Signed-off-by: Sergej Pupykin Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

serial: 8250_pci: Add Intel Broadwell ports

2016-02-15T20:42:34Z

[ Upstream commit 6c55d9b98335f7f6bd5f061866ff1633401f3a44 ] Some recent (early 2015) macbooks have Intel Broadwell where LPSS UARTs are PCI enumerated instead of ACPI. The LPSS UART block is pretty much same as used on Intel Baytrail so we can reuse the existing Baytrail setup code. Add both Broadwell LPSS UART ports to the list of supported devices. Signed-off-by: Leif Liddy Signed-off-by: Mika Westerberg Reviewed-by: Andy Shevchenko Reviewed-by: Heikki Krogerus Cc: stable Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

n_tty: Fix unsafe reference to "other" ldisc

2016-02-15T20:42:32Z

[ Upstream commit 6d27a63caad3f13e96cf065d2d96828c2006be6b ] Although n_tty_check_unthrottle() has a valid ldisc reference (since the tty core gets the ldisc ref in tty_read() before calling the line discipline read() method), it does not have a valid ldisc reference to the "other" pty of a pty pair. Since getting an ldisc reference for tty->link essentially open-codes tty_wakeup(), just replace with the equivalent tty_wakeup(). Cc: Signed-off-by: Peter Hurley Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

tty: Fix unsafe ldisc reference via ioctl(TIOCGETD)

2016-02-15T20:42:32Z

[ Upstream commit 5c17c861a357e9458001f021a7afa7aab9937439 ] 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. Cc: Signed-off-by: Peter Hurley Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

serial: 8250_pci: Add support for 12 port Exar boards

2015-11-15T17:51:53Z

[ Upstream commit be32c0cf0462c36f482b5ddcff1d8371be1e183c ] The Exar XR17V358 can also be combined with a XR17V354 chip to act as a single 12 port chip. This works the same way as the combining two XR17V358 chips. But the reported device id then is 0x4358. Signed-off-by: Soeren Grunewald Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

serial: 8250_pci: Add support for 16 port Exar boards

2015-11-15T17:51:53Z

[ Upstream commit 96a5d18bc1338786fecac73599f1681f59a59a8e ] The Exar XR17V358 chip usually provides only 8 ports. But two chips can be combined to act as a single 16 port chip. Therefor one chip is configured as master the second as slave by connecting the mode pin to VCC (master) or GND (slave). Then the master chip is reporting a different device-id depending on whether a slave is detected or not. The UARTs 8-15 are addressed from 0x2000-0x3fff. So the offset of 0x400 from UART to UART can be used to address all 16 ports as before. See: https://www.exar.com/common/content/document.ashx?id=1587 page 11 Signed-off-by: Soeren Grunewald Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin