summaryrefslogtreecommitdiff
path: root/drivers/tty/tty_io.c
AgeCommit message (Collapse)AuthorFilesLines
2021-05-14tty: fix return value for unsupported ioctlsJohan Hovold1-4/+4
[ Upstream commit 1b8b20868a6d64cfe8174a21b25b74367bdf0560 ] Drivers should return -ENOTTY ("Inappropriate I/O control operation") when an ioctl isn't supported, while -EINVAL is used for invalid arguments. Fix up the TIOCMGET, TIOCMSET and TIOCGICOUNT helpers which returned -EINVAL when a tty driver did not implement the corresponding operations. Note that the TIOCMGET and TIOCMSET helpers predate git and do not get a corresponding Fixes tag below. Fixes: d281da7ff6f7 ("tty: Make tiocgicount a handler") Signed-off-by: Johan Hovold <johan@kernel.org> Link: https://lore.kernel.org/r/20210407095208.31838-3-johan@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-03-07tty: fix up hung_up_tty_read() conversionLinus Torvalds1-4/+5
commit ddc5fda7456178e2cbc87675b370920d98360daf upstream. In commit "tty: implement read_iter", I left the read_iter conversion of the hung up tty case alone, because I incorrectly thought it didn't matter. Jiri showed me the errors of my ways, and pointed out the problems with that incomplete conversion. Fix it all up. Reported-by: Jiri Slaby <jirislaby@kernel.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Reviewed-by: Jiri Slaby <jirislaby@kernel.org> Link: https://lore.kernel.org/r/CAHk-=wh+-rGsa=xruEWdg_fJViFG8rN9bpLrfLz=_yBYh2tBhA@mail.gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-07tty: fix up iterate_tty_read() EOVERFLOW handlingLinus Torvalds1-6/+13
commit e71a8d5cf4b4f274740e31b601216071e2a11afa upstream. When I converted the tty_ldisc_ops 'read()' function to take a kernel pointer, I was a bit too aggressive about the ldisc returning EOVERFLOW. Yes, we want to have EOVERFLOW override any partially read data (because the whole point is that the buffer was too small for the whole packet, and we don't want to see partial packets), but it shouldn't override a previous EFAULT. And in fact, it really is just EOVERFLOW that is special and should throw away any partially read data, not "any error". Admittedly EOVERFLOW is currently the only one that can happen for a continuation read - and if the first read iteration returns an error we won't have this issue. So this is more of a technicality, but let's just make the intent very explicit, and re-organize the error handling a bit so that this is all clearer. Reported-by: Jiri Slaby <jirislaby@kernel.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Reviewed-by: Jiri Slaby <jirislaby@kernel.org> Link: https://lore.kernel.org/r/CAHk-=wh+-rGsa=xruEWdg_fJViFG8rN9bpLrfLz=_yBYh2tBhA@mail.gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-04tty: implement read_iterLinus Torvalds1-18/+18
[ Upstream commit dd78b0c483e33225e0e0782b0ed887129b00f956 ] Now that the ldisc read() function takes kernel pointers, it's fairly straightforward to make the tty file operations use .read_iter() instead of .read(). That automatically gives us vread() and friends, and also makes it possible to do .splice_read() on ttys again. Fixes: 36e2c7421f02 ("fs: don't allow splice read/write without explicit ops") Reported-by: Oliver Giles <ohw.giles@gmail.com> Cc: Christoph Hellwig <hch@lst.de> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-03-04tty: convert tty_ldisc_ops 'read()' function to take a kernel pointerLinus Torvalds1-3/+61
[ Upstream commit 3b830a9c34d5897be07176ce4e6f2d75e2c8cfd7 ] The tty line discipline .read() function was passed the final user pointer destination as an argument, which doesn't match the 'write()' function, and makes it very inconvenient to do a splice method for ttys. This is a conversion to use a kernel buffer instead. NOTE! It does this by passing the tty line discipline ->read() function an additional "cookie" to fill in, and an offset into the cookie data. The line discipline can fill in the cookie data with its own private information, and then the reader will repeat the read until either the cookie is cleared or it runs out of data. The only real user of this is N_HDLC, which can use this to handle big packets, even if the kernel buffer is smaller than the whole packet. Cc: Christoph Hellwig <hch@lst.de> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-02-23tty: protect tty_write from odd low-level tty disciplinesLinus Torvalds1-1/+4
commit 3342ff2698e9720f4040cc458a2744b2b32f5c3a upstream. Al root-caused a new warning from syzbot to the ttyprintk tty driver returning a write count larger than the data the tty layer actually gave it. Which confused the tty write code mightily, and with the new iov_iter based code, caused a WARNING in iov_iter_revert(). syzbot correctly bisected the source of the new warning to commit 9bb48c82aced ("tty: implement write_iter"), but the oddity goes back much further, it just didn't get caught by anything before. Reported-by: syzbot+3d2c27c2b7dc2a94814d@syzkaller.appspotmail.com Fixes: 9bb48c82aced ("tty: implement write_iter") Debugged-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-02-03tty: avoid using vfs_iocb_iter_write() for redirected console writesLinus Torvalds1-3/+17
commit a9cbbb80e3e7dd38ceac166e0698f161862a18ae upstream. It turns out that the vfs_iocb_iter_{read,write}() functions are entirely broken, and don't actually use the passed-in file pointer for IO - only for the preparatory work (permission checking and for the write_iter function lookup). That worked fine for overlayfs, which always builds the new iocb with the same file pointer that it passes in, but in the general case it ends up doing nonsensical things (and could cause an iterator call that doesn't even match the passed-in file pointer). This subtly broke the tty conversion to write_iter in commit 9bb48c82aced ("tty: implement write_iter"), because the console redirection didn't actually end up redirecting anything, since the passed-in file pointer was basically ignored, and the actual write was done with the original non-redirected console tty after all. The main visible effect of this is that the console messages were no longer logged to /var/log/boot.log during graphical boot. Fix the issue by simply not using the vfs write "helper" function at all, and just redirecting the write entirely internally to the tty layer. Do the target writability permission checks when actually registering the target tty with TIOCCONS instead of at write time. Fixes: 9bb48c82aced ("tty: implement write_iter") Reported-and-tested-by: Hans de Goede <hdegoede@redhat.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: stable@kernel.org Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-01-27Commit 9bb48c82aced ("tty: implement write_iter") converted the tty layer to ↵Sami Tolvanen1-2/+0
use write_iter. Fix the redirected_tty_write declaration also in n_tty and change the comparisons to use write_iter instead of write. also in n_tty and change the comparisons to use write_iter instead of write. commit 9f12e37cae44a96132fc3031535a0b165486941a upstream. [ Also moved the declaration of redirected_tty_write() to the proper location in a header file. The reason for the bug was the bogus extern declaration in n_tty.c silently not matching the changed definition in tty_io.c, and because it wasn't in a shared header file, there was no cross-checking of the declaration. Sami noticed because Clang's Control Flow Integrity checking ended up incidentally noticing the inconsistent declaration. - Linus ] Fixes: 9bb48c82aced ("tty: implement write_iter") Signed-off-by: Sami Tolvanen <samitolvanen@google.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-01-27tty: fix up hung_up_tty_write() conversionLinus Torvalds1-4/+5
commit 17749851eb9ca2298e7c3b81aae4228961b36f28 upstream. In commit "tty: implement write_iter", I left the write_iter conversion of the hung up tty case alone, because I incorrectly thought it didn't matter. Jiri showed me the errors of my ways, and pointed out the problems with that incomplete conversion. Fix it all up. Reported-by: Jiri Slaby <jirislaby@kernel.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Reviewed-by: Jiri Slaby <jirislaby@kernel.org> Link: https://lore.kernel.org/r/CAHk-=wh+-rGsa=xruEWdg_fJViFG8rN9bpLrfLz=_yBYh2tBhA@mail.gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-01-27tty: implement write_iterLinus Torvalds1-22/+26
commit 9bb48c82aced07698a2d08ee0f1475a6c4f6b266 upstream. This makes the tty layer use the .write_iter() function instead of the traditional .write() functionality. That allows writev(), but more importantly also makes it possible to enable .splice_write() for ttys, reinstating the "splice to tty" functionality that was lost in commit 36e2c7421f02 ("fs: don't allow splice read/write without explicit ops"). Fixes: 36e2c7421f02 ("fs: don't allow splice read/write without explicit ops") Reported-by: Oliver Giles <ohw.giles@gmail.com> Cc: Christoph Hellwig <hch@lst.de> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-04tty: Fix ->session lockingJann Horn1-1/+6
Currently, locking of ->session is very inconsistent; most places protect it using the legacy tty mutex, but disassociate_ctty(), __do_SAK(), tiocspgrp() and tiocgsid() don't. Two of the writers hold the ctrl_lock (because they already need it for ->pgrp), but __proc_set_tty() doesn't do that yet. On a PREEMPT=y system, an unprivileged user can theoretically abuse this broken locking to read 4 bytes of freed memory via TIOCGSID if tiocgsid() is preempted long enough at the right point. (Other things might also go wrong, especially if root-only ioctls are involved; I'm not sure about that.) Change the locking on ->session such that: - tty_lock() is held by all writers: By making disassociate_ctty() hold it. This should be fine because the same lock can already be taken through the call to tty_vhangup_session(). The tricky part is that we need to shorten the area covered by siglock to be able to take tty_lock() without ugly retry logic; as far as I can tell, this should be fine, since nothing in the signal_struct is touched in the `if (tty)` branch. - ctrl_lock is held by all writers: By changing __proc_set_tty() to hold the lock a little longer. - All readers that aren't holding tty_lock() hold ctrl_lock: By adding locking to tiocgsid() and __do_SAK(), and expanding the area covered by ctrl_lock in tiocspgrp(). Cc: stable@kernel.org Signed-off-by: Jann Horn <jannh@google.com> Reviewed-by: Jiri Slaby <jirislaby@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-11-06tty: fix crash in release_tty if tty->port is not setMatthias Reichl1-2/+4
Commit 2ae0b31e0face ("tty: don't crash in tty_init_dev when missing tty_port") didn't fully prevent the crash as the cleanup path in tty_init_dev() calls release_tty() which dereferences tty->port without checking it for non-null. Add tty->port checks to release_tty to avoid the kernel crash. Fixes: 2ae0b31e0face ("tty: don't crash in tty_init_dev when missing tty_port") Signed-off-by: Matthias Reichl <hias@horus.com> Link: https://lore.kernel.org/r/20201105123432.4448-1-hias@horus.com Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-08-18tty: fix kernel-docJiri Slaby1-14/+12
With W=1, the kernel-doc checker complains quite a lot in the tty layer. Over the time, many documented parameters were renamed, removed or switched from tty to tty_port and similar. Some were mistyped in the doc too. So fix all these in the tty core. (But do not add the missing ones which the checker complains about too. Not now.) The rest in the tty layer will follow in the next patches. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Link: https://lore.kernel.org/r/20200818085655.12071-4-jslaby@suse.cz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-07-29tty: Use the preferred form for passing the size of a structure typeGustavo A. R. Silva1-7/+7
Use the preferred form for passing the size of a structure type. The alternative form where the structure type is spelled out hurts readability and introduces an opportunity for a bug when the object type is changed but the corresponding object identifier to which the sizeof operator is applied is not. Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Acked-by: Jiri Slaby <jirislaby@kernel.org> Link: https://lore.kernel.org/r/b04dd8cdd67bd6ffde3fd12940aeef35fdb824a6.1595543280.git.gustavoars@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-07-29tty: Fix identation issues in struct serial_struct32Gustavo A. R. Silva1-19/+19
Fix the following checkpatch.pl warnings together with all the identation issues in struct serial_struct32: ERROR: code indent should use tabs where possible + char reserved_char;$ WARNING: please, no spaces at the start of a line + char reserved_char;$ ERROR: code indent should use tabs where possible + compat_int_t reserved;$ WARNING: please, no spaces at the start of a line + compat_int_t reserved;$ Acked-by: Jiri Slaby <jirislaby@kernel.org> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Link: https://lore.kernel.org/r/77576843397aeab0af8aa0423a9768f3ca8dedfb.1595543280.git.gustavoars@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-07-29tty: Avoid the use of one-element arraysGustavo A. R. Silva1-2/+2
One-element arrays are being deprecated[1]. Replace the one-element arrays with simple value types 'char reserved_char' and 'compat_int_t reserved'[2], once it seems these are just placeholders for alignment. [1] https://github.com/KSPP/linux/issues/79 [2] https://github.com/KSPP/linux/issues/86 Tested-by: kernel test robot <lkp@intel.com> Link: https://github.com/GustavoARSilva/linux-hardening/blob/master/cii/0-day/tty-20200716.md Acked-by: Jiri Slaby <jirislaby@kernel.org> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Link: https://lore.kernel.org/r/f49bf0e27eaac396c96d21392c8c284f9f5ef52a.1595543280.git.gustavoars@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-03-18tty: fix compat TIOCGSERIAL checking wrong function ptrEric Biggers1-1/+1
Commit 77654350306a ("take compat TIOC[SG]SERIAL treatment into tty_compat_ioctl()") changed the compat version of TIOCGSERIAL to start checking for the presence of the ->set_serial function pointer rather than ->get_serial. This appears to be a copy-and-paste error, since ->get_serial is the function pointer that is called as well as the pointer that is checked by the non-compat version of TIOCGSERIAL. Fix this by checking the correct function pointer. Fixes: 77654350306a ("take compat TIOC[SG]SERIAL treatment into tty_compat_ioctl()") Cc: <stable@vger.kernel.org> # v4.20+ Signed-off-by: Eric Biggers <ebiggers@google.com> Acked-by: Jiri Slaby <jslaby@suse.cz> Link: https://lore.kernel.org/r/20200224182044.234553-3-ebiggers@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-03-18tty: fix compat TIOCGSERIAL leaking uninitialized memoryEric Biggers1-1/+3
Commit 77654350306a ("take compat TIOC[SG]SERIAL treatment into tty_compat_ioctl()") changed the compat version of TIOCGSERIAL to start copying a whole 'serial_struct32' to userspace rather than individual fields, but failed to initialize all padding and fields -- namely the hole after the 'iomem_reg_shift' field, and the 'reserved' field. Fix this by initializing the struct to zero. [v2: use sizeof, and convert the adjacent line for consistency.] Reported-by: syzbot+8da9175e28eadcb203ce@syzkaller.appspotmail.com Fixes: 77654350306a ("take compat TIOC[SG]SERIAL treatment into tty_compat_ioctl()") Cc: <stable@vger.kernel.org> # v4.20+ Signed-off-by: Eric Biggers <ebiggers@google.com> Acked-by: Jiri Slaby <jslaby@suse.cz> Link: https://lore.kernel.org/r/20200224182044.234553-2-ebiggers@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-03-18tty: drop outdated comments about release_tty() lockingEric Biggers1-6/+2
The current version of the TTY code unlocks the tty_struct(s) before release_tty() rather than after. Moreover, tty_unlock_pair() no longer exists. Thus, remove the outdated comments regarding tty_unlock_pair(). Signed-off-by: Eric Biggers <ebiggers@google.com> Link: https://lore.kernel.org/r/20200224073359.292795-1-ebiggers@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-12-17tty: drop useless variable initialisation in tty_kopen()Uwe Kleine-König1-1/+1
The driver variable is assigned to unconditionally and not used before. So there is no need to explicitly initialize it at the start of tty_kopen(). Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20191217075040.8020-1-u.kleine-koenig@pengutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-12-03Merge tag 'tty-5.5-rc1' of ↵Linus Torvalds1-6/+8
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty Pull tty/serial updates from Greg KH: "Here is the "big" tty and serial driver patches for 5.5-rc1. It's a bit later in the merge window than normal as I wanted to make sure some last-minute patches applied to it were all sane. They seem to be :) There's a lot of little stuff in here, for the tty core, and for lots of serial drivers: - reverts of uartlite serial driver patches that were wrong - msm-serial driver fixes - serial core updates and fixes - tty core fixes - serial driver dma mapping api changes - lots of other tiny fixes and updates for serial drivers All of these have been in linux-next for a while with no reported issues" * tag 'tty-5.5-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty: (58 commits) Revert "serial/8250: Add support for NI-Serial PXI/PXIe+485 devices" vcs: prevent write access to vcsu devices tty: vt: keyboard: reject invalid keycodes tty: don't crash in tty_init_dev when missing tty_port serial: stm32: fix clearing interrupt error flags tty: Fix Kconfig indentation, continued serial: serial_core: Perform NULL checks for break_ctl ops tty: remove unused argument from tty_open_by_driver() tty: Fix Kconfig indentation {tty: serial, nand: onenand}: samsung: rename to fix build warning serial: ifx6x60: add missed pm_runtime_disable serial: pl011: Fix DMA ->flush_buffer() Revert "serial-uartlite: Move the uart register" Revert "serial-uartlite: Add get serial id if not provided" Revert "serial-uartlite: Do not use static struct uart_driver out of probe()" Revert "serial-uartlite: Add runtime support" Revert "serial-uartlite: Change logic how console_port is setup" Revert "serial-uartlite: Use allocated structure instead of static ones" tty: serial: msm_serial: Use dma_request_chan() directly for channel request tty: serial: tegra: Use dma_request_chan() directly for channel request ...
2019-11-22tty: don't crash in tty_init_dev when missing tty_portJiri Slaby1-3/+6
We currently warn the user when tty->port is not set in tty_init_dev yet. The warning says that the kernel will crash later. And it really will only few lines below at: tty->port->itty = tty; So be nice and avoid the crash -- return an error instead. And update the warning. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Cc: Sudip Mukherjee <sudipm.mukherjee@gmail.com> Link: https://lore.kernel.org/r/20191122101721.7222-1-jslaby@suse.cz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-11-20tty: remove unused argument from tty_open_by_driver()Sudip Mukherjee1-3/+2
The argument 'inode' passed to tty_open_by_driver() was not being used. Remove the extra argument. Signed-off-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com> Link: https://lore.kernel.org/r/20191120151709.14148-1-sudipm.mukherjee@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-10-23tty: handle compat PPP ioctlsArnd Bergmann1-0/+4
Multiple tty devices are have tty devices that handle the PPPIOCGUNIT and PPPIOCGCHAN ioctls. To avoid adding a compat_ioctl handler to each of those, add it directly in tty_compat_ioctl so we can remove the calls from fs/compat_ioctl.c. Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Paul Mackerras <paulus@samba.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2019-10-23compat_ioctl: move SIOCOUTQ out of compat_ioctl.cArnd Bergmann1-0/+1
All users of this call are in socket or tty code, so handling it there means we can avoid the table entry in fs/compat_ioctl.c. Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Eric Dumazet <edumazet@google.com> Cc: netdev@vger.kernel.org Cc: "David S. Miller" <davem@davemloft.net> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2019-07-30drivers: Introduce device lookup variants by device typeSuzuki K Poulose1-7/+1
Add a helper to match a device by its type and provide wrappers for {bus/class/driver}_find_device() APIs. Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Harald Freudenberger <freude@linux.ibm.com> Cc: Heiko Carstens <heiko.carstens@de.ibm.com> Cc: linux-usb@vger.kernel.org Cc: Oliver Neukum <oneukum@suse.com> Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Cc: Tomas Winkler <tomas.winkler@intel.com> Cc: "Rafael J. Wysocki" <rafael@kernel.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Ulf Hansson <ulf.hansson@linaro.org> Cc: Joe Perches <joe@perches.com> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com> Link: https://lore.kernel.org/r/20190723221838.12024-5-suzuki.poulose@arm.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-24tty: tty_io: fix driver refcount imbalance on error pathLin Yi1-1/+3
tty_lookup_driver take a reference to the struct tty_driver, but forget to release it on the error path, lead to a memory leak. add a tty_driver_kref_put before error return. Signed-off-by: Lin Yi <teroincn@163.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-04-25tty: update obsolete termios commentJohan Hovold1-1/+1
Update an obsolete comment referring to the termios_locked structure which was removed over a decade ago by commit fe6e29fdb1a7 ("tty: simplify ktermios allocation"). While at it, fix the "Thus" typo. Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-03-29Revert "tty: pty: Fix race condition between release_one_tty and pty_write"Greg Kroah-Hartman1-3/+0
This reverts commit b9ca5f8560af244489b4a1bc1ae88b341f24bc95 as 0-day shows it has a circular locking dependency. Fixes: b9ca5f8560af ("tty: pty: Fix race condition between release_one_tty and pty_write") Reported-by: kernel test robot <lkp@intel.com> Cc: Sahara <keun-o.park@darkmatter.ae> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-03-28tty: pty: Fix race condition between release_one_tty and pty_writeSahara1-0/+3
Especially when a linked tty is used such as pty, the linked tty port's buf works have not been cancelled while master tty port's buf work has been cancelled. Since release_one_tty and flush_to_ldisc run in workqueue threads separately, when pty_cleanup happens and link tty port is freed, flush_to_ldisc tries to access freed port and port->itty, eventually it causes a panic. This patch utilizes the magic value with holding the tty_mutex to check if the tty->link is valid. Fixes: 2b022ab7542d ("pty: cancel pty slave port buf's work in tty_release") Signed-off-by: Sahara <keun-o.park@darkmatter.ae> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-01-30tty: ldisc: add sysctl to prevent autoloading of ldiscsGreg Kroah-Hartman1-0/+3
By default, the kernel will automatically load the module of any line dicipline that is asked for. As this sometimes isn't the safest thing to do, provide a sysctl to disable this feature. By default, we set this to 'y' as that is the historical way that Linux has worked, and we do not want to break working systems. But in the future, perhaps this can default to 'n' to prevent this functionality. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Theodore Ts'o <tytso@mit.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-01-21tty: Handle problem if line discipline does not have receive_bufGreg Kroah-Hartman1-1/+2
Some tty line disciplines do not have a receive buf callback, so properly check for that before calling it. If they do not have this callback, just eat the character quietly, as we can't fail this call. Reported-by: Jann Horn <jannh@google.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-01-11tty: Don't hold ldisc lock in tty_reopen() if ldisc presentDmitry Safonov1-7/+13
Try to get reference for ldisc during tty_reopen(). If ldisc present, we don't need to do tty_ldisc_reinit() and lock the write side for line discipline semaphore. Effectively, it optimizes fast-path for tty_reopen(), but more importantly it won't interrupt ongoing IO on the tty as no ldisc change is needed. Fixes user-visible issue when tty_reopen() interrupted login process for user with a long password, observed and reported by Lukas. Fixes: c96cf923a98d ("tty: Don't block on IO when ldisc change is pending") Fixes: 83d817f41070 ("tty: Hold tty_ldisc_lock() during tty_reopen()") Cc: Jiri Slaby <jslaby@suse.com> Reported-by: Lukas F. Hartmann <lukas@mntmn.com> Tested-by: Lukas F. Hartmann <lukas@mntmn.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Dmitry Safonov <dima@arista.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-12-10Merge 4.20-rc6 into tty-nextGreg Kroah-Hartman1-2/+9
We want the TTY changes in here as well. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-12-05tty: Simplify tty->count math in tty_reopen()Dmitry Safonov1-8/+5
As notted by Jiri, tty_ldisc_reinit() shouldn't rely on tty counter. Simplify math by increasing the counter after reinit success. Cc: Jiri Slaby <jslaby@suse.com> Link: lkml.kernel.org/r/<20180829022353.23568-2-dima@arista.com> Suggested-by: Jiri Slaby <jslaby@suse.com> Reviewed-by: Jiri Slaby <jslaby@suse.cz> Tested-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Dmitry Safonov <dima@arista.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-12-05tty: Hold tty_ldisc_lock() during tty_reopen()Dmitry Safonov1-2/+7
tty_ldisc_reinit() doesn't race with neither tty_ldisc_hangup() nor set_ldisc() nor tty_ldisc_release() as they use tty lock. But it races with anyone who expects line discipline to be the same after hoding read semaphore in tty_ldisc_ref(). We've seen the following crash on v4.9.108 stable: BUG: unable to handle kernel paging request at 0000000000002260 IP: [..] n_tty_receive_buf_common+0x5f/0x86d Workqueue: events_unbound flush_to_ldisc Call Trace: [..] n_tty_receive_buf2 [..] tty_ldisc_receive_buf [..] flush_to_ldisc [..] process_one_work [..] worker_thread [..] kthread [..] ret_from_fork tty_ldisc_reinit() should be called with ldisc_sem hold for writing, which will protect any reader against line discipline changes. Cc: Jiri Slaby <jslaby@suse.com> Cc: stable@vger.kernel.org # b027e2298bd5 ("tty: fix data race between tty_init_dev and flush of buf") Reviewed-by: Jiri Slaby <jslaby@suse.cz> Reported-by: syzbot+3aa9784721dfb90e984d@syzkaller.appspotmail.com Tested-by: Mark Rutland <mark.rutland@arm.com> Tested-by: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> Signed-off-by: Dmitry Safonov <dima@arista.com> Tested-by: Tycho Andersen <tycho@tycho.ws> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-12-05USB: serial: console: fix reported terminal settingsJohan Hovold1-2/+9
The USB-serial console implementation has never reported the actual terminal settings used. Despite storing the corresponding cflags in its struct console, these were never honoured on later tty open() where the tty termios would be left initialised to the driver defaults. Unlike the serial console implementation, the USB-serial code calls subdriver open() already at console setup. While calling set_termios() and write() before open() looks like it could work for some USB-serial drivers, others definitely do not expect this, so modelling this after serial core is going to be intrusive, if at all possible. Instead, use a (renamed) tty helper to save the termios data used at console setup so that the tty termios reflects the actual terminal settings after a subsequent tty open(). Note that the calls to tty_init_termios() (tty_driver_install()) and tty_save_termios() are serialised using the disconnect mutex. This specifically fixes a regression that was triggered by a recent change adding software flow control to the pl2303 driver: a getty trying to disable flow control while leaving the baud rate unchanged would now also set the baud rate to the driver default (prior to the flow-control change this had been a noop). Fixes: 7041d9c3f01b ("USB: serial: pl2303: add support for tx xon/xoff flow control") Cc: stable <stable@vger.kernel.org> # 4.18 Cc: Florian Zumbiehl <florz@florz.de> Reported-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Tested-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Johan Hovold <johan@kernel.org>
2018-10-29Merge tag 'tty-4.20-rc1' of ↵Linus Torvalds1-1/+1
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty Pull tty/serial updates from Greg KH: "Here is the big tty and serial pull request for 4.20-rc1 Lots of little things here, including a merge from the SPI tree in order to keep things simpler for everyone to sync around for one platform. Major stuff is: - tty buffer clearing after use - atmel_serial fixes and additions - xilinx uart driver updates and of course, lots of tiny fixes and additions to individual serial drivers. All of these have been in linux-next with no reported issues for a while" * tag 'tty-4.20-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty: (66 commits) of: base: Change logic in of_alias_get_alias_list() of: base: Fix english spelling in of_alias_get_alias_list() serial: sh-sci: do not warn if DMA transfers are not supported serial: uartps: Do not allow use aliases >= MAX_UART_INSTANCES tty: check name length in tty_find_polling_driver() serial: sh-sci: Add r8a77990 support tty: wipe buffer if not echoing data tty: wipe buffer. serial: fsl_lpuart: Remove the alias node dependence TTY: sn_console: Replace spin_is_locked() with spin_trylock() Revert "serial:serial_core: Allow use of CTS for PPS line discipline" serial: 8250_uniphier: add auto-flow-control support serial: 8250_uniphier: flatten probe function serial: 8250_uniphier: remove unused "fifo-size" property dt-bindings: serial: sh-sci: Document r8a7744 bindings serial: uartps: Fix missing unlock on error in cdns_get_id() tty/serial: atmel: add ISO7816 support tty/serial_core: add ISO7816 infrastructure serial:serial_core: Allow use of CTS for PPS line discipline serial: docs: Fix filename for serial reference implementation ...
2018-10-24Merge branch 'work.tty-ioctl' of ↵Linus Torvalds1-43/+186
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs Pull tty ioctl updates from Al Viro: "This is the compat_ioctl work related to tty ioctls. Quite a bit of dead code taken out, all tty-related stuff gone from fs/compat_ioctl.c. A bunch of compat bugs fixed - some still remain, but all more or less generic tty-related ioctls should be covered (remaining issues are in things like driver-private ioctls in a pcmcia serial card driver not getting properly handled in 32bit processes on 64bit host, etc)" * 'work.tty-ioctl' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: (53 commits) kill TIOCSERGSTRUCT change semantics of ldisc ->compat_ioctl() kill TIOCSER[SG]WILD synclink_gt(): fix compat_ioctl() pty: fix compat ioctls compat_ioctl - kill keyboard ioctl handling gigaset: add ->compat_ioctl() vt_compat_ioctl(): clean up, use compat_ptr() properly gigaset: don't try to printk userland buffer contents dgnc: don't bother with (empty) stub for TCXONC dgnc: leave TIOC[GS]SOFTCAR to ldisc remove fallback to drivers for TIOCGICOUNT dgnc: break-related ioctls won't reach ->ioctl() kill the rest of tty COMPAT_IOCTL() entries dgnc: TIOCM... won't reach ->ioctl() isdn_tty: TCSBRK{,P} won't reach ->ioctl() kill capinc_tty_ioctl() take compat TIOC[SG]SERIAL treatment into tty_compat_ioctl() synclink: reduce pointless checks in ->ioctl() complete ->[sg]et_serial() switchover ...
2018-10-24Merge branch 'siginfo-linus' of ↵Linus Torvalds1-3/+3
git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace Pull siginfo updates from Eric Biederman: "I have been slowly sorting out siginfo and this is the culmination of that work. The primary result is in several ways the signal infrastructure has been made less error prone. The code has been updated so that manually specifying SEND_SIG_FORCED is never necessary. The conversion to the new siginfo sending functions is now complete, which makes it difficult to send a signal without filling in the proper siginfo fields. At the tail end of the patchset comes the optimization of decreasing the size of struct siginfo in the kernel from 128 bytes to about 48 bytes on 64bit. The fundamental observation that enables this is by definition none of the known ways to use struct siginfo uses the extra bytes. This comes at the cost of a small user space observable difference. For the rare case of siginfo being injected into the kernel only what can be copied into kernel_siginfo is delivered to the destination, the rest of the bytes are set to 0. For cases where the signal and the si_code are known this is safe, because we know those bytes are not used. For cases where the signal and si_code combination is unknown the bits that won't fit into struct kernel_siginfo are tested to verify they are zero, and the send fails if they are not. I made an extensive search through userspace code and I could not find anything that would break because of the above change. If it turns out I did break something it will take just the revert of a single change to restore kernel_siginfo to the same size as userspace siginfo. Testing did reveal dependencies on preferring the signo passed to sigqueueinfo over si->signo, so bit the bullet and added the complexity necessary to handle that case. Testing also revealed bad things can happen if a negative signal number is passed into the system calls. Something no sane application will do but something a malicious program or a fuzzer might do. So I have fixed the code that performs the bounds checks to ensure negative signal numbers are handled" * 'siginfo-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace: (80 commits) signal: Guard against negative signal numbers in copy_siginfo_from_user32 signal: Guard against negative signal numbers in copy_siginfo_from_user signal: In sigqueueinfo prefer sig not si_signo signal: Use a smaller struct siginfo in the kernel signal: Distinguish between kernel_siginfo and siginfo signal: Introduce copy_siginfo_from_user and use it's return value signal: Remove the need for __ARCH_SI_PREABLE_SIZE and SI_PAD_SIZE signal: Fail sigqueueinfo if si_signo != sig signal/sparc: Move EMT_TAGOVF into the generic siginfo.h signal/unicore32: Use force_sig_fault where appropriate signal/unicore32: Generate siginfo in ucs32_notify_die signal/unicore32: Use send_sig_fault where appropriate signal/arc: Use force_sig_fault where appropriate signal/arc: Push siginfo generation into unhandled_exception signal/ia64: Use force_sig_fault where appropriate signal/ia64: Use the force_sig(SIGSEGV,...) in ia64_rt_sigreturn signal/ia64: Use the generic force_sigsegv in setup_frame signal/arm/kvm: Use send_sig_mceerr signal/arm: Use send_sig_fault where appropriate signal/arm: Use force_sig_fault where appropriate ...
2018-10-13change semantics of ldisc ->compat_ioctl()Al Viro1-0/+3
First of all, make it return int. Returning long when native method had never allowed that is ridiculous and inconvenient. More importantly, change the caller; if ldisc ->compat_ioctl() is NULL or returns -ENOIOCTLCMD, tty_compat_ioctl() will try to feed cmd and compat_ptr(arg) to ldisc's native ->ioctl(). That simplifies ->compat_ioctl() instances quite a bit - they only need to deal with ioctls that are neither generic tty ones (those would get shunted off to tty_ioctl()) nor simple compat pointer ones. Note that something like TCFLSH won't reach ->compat_ioctl(), even if ldisc ->ioctl() does handle it - it will be recognized earlier and passed to tty_ioctl() (and ultimately - ldisc ->ioctl()). For many ldiscs it means that NULL ->compat_ioctl() does the right thing. Those where it won't serve (see e.g. n_r3964.c) are also easily dealt with - we need to handle the numeric-argument ioctls (calling the native instance) and, if such would exist, the ioctls that need layout conversion, etc. All in-tree ldiscs dealt with. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2018-10-13remove fallback to drivers for TIOCGICOUNTAl Viro1-5/+1
none of them handles it anyway. Reviewed-by: Johan Hovold <johan@kernel.org> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2018-10-13take compat TIOC[SG]SERIAL treatment into tty_compat_ioctl()Al Viro1-0/+81
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2018-10-13complete ->[sg]et_serial() switchoverAl Viro1-10/+4
Reviewed-by: Johan Hovold <johan@kernel.org> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2018-10-11tty: check name length in tty_find_polling_driver()Miles Chen1-1/+1
The issue is found by a fuzzing test. If tty_find_polling_driver() recevies an incorrect input such as ',,' or '0b', the len becomes 0 and strncmp() always return 0. In this case, a null p->ops->poll_init() is called and it causes a kernel panic. Fix this by checking name length against zero in tty_find_polling_driver(). $echo ,, > /sys/module/kgdboc/parameters/kgdboc [ 20.804451] WARNING: CPU: 1 PID: 104 at drivers/tty/serial/serial_core.c:457 uart_get_baud_rate+0xe8/0x190 [ 20.804917] Modules linked in: [ 20.805317] CPU: 1 PID: 104 Comm: sh Not tainted 4.19.0-rc7ajb #8 [ 20.805469] Hardware name: linux,dummy-virt (DT) [ 20.805732] pstate: 20000005 (nzCv daif -PAN -UAO) [ 20.805895] pc : uart_get_baud_rate+0xe8/0x190 [ 20.806042] lr : uart_get_baud_rate+0xc0/0x190 [ 20.806476] sp : ffffffc06acff940 [ 20.806676] x29: ffffffc06acff940 x28: 0000000000002580 [ 20.806977] x27: 0000000000009600 x26: 0000000000009600 [ 20.807231] x25: ffffffc06acffad0 x24: 00000000ffffeff0 [ 20.807576] x23: 0000000000000001 x22: 0000000000000000 [ 20.807807] x21: 0000000000000001 x20: 0000000000000000 [ 20.808049] x19: ffffffc06acffac8 x18: 0000000000000000 [ 20.808277] x17: 0000000000000000 x16: 0000000000000000 [ 20.808520] x15: ffffffffffffffff x14: ffffffff00000000 [ 20.808757] x13: ffffffffffffffff x12: 0000000000000001 [ 20.809011] x11: 0101010101010101 x10: ffffff880d59ff5f [ 20.809292] x9 : ffffff880d59ff5e x8 : ffffffc06acffaf3 [ 20.809549] x7 : 0000000000000000 x6 : ffffff880d59ff5f [ 20.809803] x5 : 0000000080008001 x4 : 0000000000000003 [ 20.810056] x3 : ffffff900853e6b4 x2 : dfffff9000000000 [ 20.810693] x1 : ffffffc06acffad0 x0 : 0000000000000cb0 [ 20.811005] Call trace: [ 20.811214] uart_get_baud_rate+0xe8/0x190 [ 20.811479] serial8250_do_set_termios+0xe0/0x6f4 [ 20.811719] serial8250_set_termios+0x48/0x54 [ 20.811928] uart_set_options+0x138/0x1bc [ 20.812129] uart_poll_init+0x114/0x16c [ 20.812330] tty_find_polling_driver+0x158/0x200 [ 20.812545] configure_kgdboc+0xbc/0x1bc [ 20.812745] param_set_kgdboc_var+0xb8/0x150 [ 20.812960] param_attr_store+0xbc/0x150 [ 20.813160] module_attr_store+0x40/0x58 [ 20.813364] sysfs_kf_write+0x8c/0xa8 [ 20.813563] kernfs_fop_write+0x154/0x290 [ 20.813764] vfs_write+0xf0/0x278 [ 20.813951] __arm64_sys_write+0x84/0xf4 [ 20.814400] el0_svc_common+0xf4/0x1dc [ 20.814616] el0_svc_handler+0x98/0xbc [ 20.814804] el0_svc+0x8/0xc [ 20.822005] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 20.826913] Mem abort info: [ 20.827103] ESR = 0x84000006 [ 20.827352] Exception class = IABT (current EL), IL = 16 bits [ 20.827655] SET = 0, FnV = 0 [ 20.827855] EA = 0, S1PTW = 0 [ 20.828135] user pgtable: 4k pages, 39-bit VAs, pgdp = (____ptrval____) [ 20.828484] [0000000000000000] pgd=00000000aadee003, pud=00000000aadee003, pmd=0000000000000000 [ 20.829195] Internal error: Oops: 84000006 [#1] SMP [ 20.829564] Modules linked in: [ 20.829890] CPU: 1 PID: 104 Comm: sh Tainted: G W 4.19.0-rc7ajb #8 [ 20.830545] Hardware name: linux,dummy-virt (DT) [ 20.830829] pstate: 60000085 (nZCv daIf -PAN -UAO) [ 20.831174] pc : (null) [ 20.831457] lr : serial8250_do_set_termios+0x358/0x6f4 [ 20.831727] sp : ffffffc06acff9b0 [ 20.831936] x29: ffffffc06acff9b0 x28: ffffff9008d7c000 [ 20.832267] x27: ffffff900969e16f x26: 0000000000000000 [ 20.832589] x25: ffffff900969dfb0 x24: 0000000000000000 [ 20.832906] x23: f