Skip to content

K
Kernel

openeuler / Kernel
大约 2 年 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 29 3月, 2023 1 次提交
  3. 19 10月, 2021 1 次提交
  5. 03 6月, 2021 1 次提交
  7. 09 4月, 2021 4 次提交
  9. 09 3月, 2021 1 次提交
  11. 09 2月, 2021 1 次提交
    • L
      tty: avoid using vfs_iocb_iter_write() for redirected console writes · 2037cd7d
      由 Linus Torvalds 提交于 
      stable inclusion
from stable-5.10.13
commit 8fe07159fc53d8103da4ca9899be782ec478692f
bugzilla: 47995

--------------------------------

commit a9cbbb80 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
9bb48c82 ("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: 9bb48c82 ("tty: implement write_iter")
Reported-and-tested-by: NHans de Goede <hdegoede@redhat.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: stable@kernel.org
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
      2037cd7d
  13. 08 2月, 2021 3 次提交
  15. 05 12月, 2020 1 次提交
    • J
      tty: Fix ->session locking · c8bcd9c5
      由 Jann Horn 提交于 
      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: NJann Horn <jannh@google.com>
Reviewed-by: NJiri Slaby <jirislaby@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c8bcd9c5
  17. 07 11月, 2020 1 次提交
  19. 18 8月, 2020 1 次提交
  21. 29 7月, 2020 3 次提交
  23. 18 3月, 2020 3 次提交
  25. 17 12月, 2019 1 次提交
  27. 22 11月, 2019 1 次提交
  29. 20 11月, 2019 1 次提交
  31. 23 10月, 2019 2 次提交
  33. 30 7月, 2019 1 次提交
  35. 24 5月, 2019 1 次提交
  37. 25 4月, 2019 1 次提交
  39. 29 3月, 2019 1 次提交
  41. 28 3月, 2019 1 次提交
    • S
      tty: pty: Fix race condition between release_one_tty and pty_write · b9ca5f85
      由 Sahara 提交于 
      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: 2b022ab7 ("pty: cancel pty slave port buf's work in tty_release")
Signed-off-by: NSahara <keun-o.park@darkmatter.ae>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b9ca5f85
  43. 30 1月, 2019 1 次提交
  45. 22 1月, 2019 1 次提交
  47. 12 1月, 2019 1 次提交
  49. 05 12月, 2018 3 次提交
    • D
      tty: Simplify tty->count math in tty_reopen() · cf62a1a1
      由 Dmitry Safonov 提交于 
      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: NJiri Slaby <jslaby@suse.com>
Reviewed-by: NJiri Slaby <jslaby@suse.cz>
Tested-by: NMark Rutland <mark.rutland@arm.com>
Signed-off-by: NDmitry Safonov <dima@arista.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      cf62a1a1
    • D
      tty: Hold tty_ldisc_lock() during tty_reopen() · 83d817f4
      由 Dmitry Safonov 提交于 
      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 # b027e229 ("tty: fix data race between tty_init_dev and flush of buf")
Reviewed-by: NJiri Slaby <jslaby@suse.cz>
Reported-by: syzbot+3aa9784721dfb90e984d@syzkaller.appspotmail.com
Tested-by: NMark Rutland <mark.rutland@arm.com>
Tested-by: NTetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Signed-off-by: NDmitry Safonov <dima@arista.com>
Tested-by: NTycho Andersen <tycho@tycho.ws>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      83d817f4
    • J
      USB: serial: console: fix reported terminal settings · f51ccf46
      由 Johan Hovold 提交于 
      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: 7041d9c3 ("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: NJarkko Nikula <jarkko.nikula@linux.intel.com>
Tested-by: NJarkko Nikula <jarkko.nikula@linux.intel.com>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NJohan Hovold <johan@kernel.org>
      f51ccf46
  51. 13 10月, 2018 3 次提交
    • A
      change semantics of ldisc ->compat_ioctl() · f0193d3e
      由 Al Viro 提交于 
      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: NAl Viro <viro@zeniv.linux.org.uk>
      f0193d3e
    • A
      remove fallback to drivers for TIOCGICOUNT · a3096199
      由 Al Viro 提交于 
      none of them handles it anyway.
Reviewed-by: NJohan Hovold <johan@kernel.org>
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      a3096199
    • A
      take compat TIOC[SG]SERIAL treatment into tty_compat_ioctl() · 77654350
      由 Al Viro 提交于 
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      77654350