05 Dec, 2020
1 commit
-
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
Reviewed-by: Jiri Slaby
Signed-off-by: Greg Kroah-Hartman
07 Nov, 2020
1 commit
-
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
Link: https://lore.kernel.org/r/20201105123432.4448-1-hias@horus.com
Cc: stable
Signed-off-by: Greg Kroah-Hartman
18 Aug, 2020
1 commit
-
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
Link: https://lore.kernel.org/r/20200818085655.12071-4-jslaby@suse.cz
Signed-off-by: Greg Kroah-Hartman
29 Jul, 2020
3 commits
-
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
Acked-by: Jiri Slaby
Link: https://lore.kernel.org/r/b04dd8cdd67bd6ffde3fd12940aeef35fdb824a6.1595543280.git.gustavoars@kernel.org
Signed-off-by: Greg Kroah-Hartman -
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
Signed-off-by: Gustavo A. R. Silva
Link: https://lore.kernel.org/r/77576843397aeab0af8aa0423a9768f3ca8dedfb.1595543280.git.gustavoars@kernel.org
Signed-off-by: Greg Kroah-Hartman -
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/86Tested-by: kernel test robot
Link: https://github.com/GustavoARSilva/linux-hardening/blob/master/cii/0-day/tty-20200716.md
Acked-by: Jiri Slaby
Signed-off-by: Gustavo A. R. Silva
Link: https://lore.kernel.org/r/f49bf0e27eaac396c96d21392c8c284f9f5ef52a.1595543280.git.gustavoars@kernel.org
Signed-off-by: Greg Kroah-Hartman
18 Mar, 2020
3 commits
-
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: # v4.20+
Signed-off-by: Eric Biggers
Acked-by: Jiri Slaby
Link: https://lore.kernel.org/r/20200224182044.234553-3-ebiggers@kernel.org
Signed-off-by: Greg Kroah-Hartman -
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: # v4.20+
Signed-off-by: Eric Biggers
Acked-by: Jiri Slaby
Link: https://lore.kernel.org/r/20200224182044.234553-2-ebiggers@kernel.org
Signed-off-by: Greg Kroah-Hartman -
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
Link: https://lore.kernel.org/r/20200224073359.292795-1-ebiggers@kernel.org
Signed-off-by: Greg Kroah-Hartman
17 Dec, 2019
1 commit
-
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
Link: https://lore.kernel.org/r/20191217075040.8020-1-u.kleine-koenig@pengutronix.de
Signed-off-by: Greg Kroah-Hartman
04 Dec, 2019
1 commit
-
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
...
22 Nov, 2019
1 commit
-
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
Cc: Sudip Mukherjee
Link: https://lore.kernel.org/r/20191122101721.7222-1-jslaby@suse.cz
Signed-off-by: Greg Kroah-Hartman
20 Nov, 2019
1 commit
-
The argument 'inode' passed to tty_open_by_driver() was not being used.
Remove the extra argument.Signed-off-by: Sudip Mukherjee
Link: https://lore.kernel.org/r/20191120151709.14148-1-sudipm.mukherjee@gmail.com
Signed-off-by: Greg Kroah-Hartman
23 Oct, 2019
2 commits
-
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
Cc: Paul Mackerras
Signed-off-by: Arnd Bergmann -
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
Cc: Eric Dumazet
Cc: netdev@vger.kernel.org
Cc: "David S. Miller"
Signed-off-by: Arnd Bergmann
30 Jul, 2019
1 commit
-
Add a helper to match a device by its type and provide wrappers
for {bus/class/driver}_find_device() APIs.Cc: Alexander Shishkin
Cc: Arnd Bergmann
Cc: Harald Freudenberger
Cc: Heiko Carstens
Cc: linux-usb@vger.kernel.org
Cc: Oliver Neukum
Cc: Sebastian Andrzej Siewior
Cc: Tomas Winkler
Cc: "Rafael J. Wysocki"
Cc: Greg Kroah-Hartman
Cc: Ulf Hansson
Cc: Joe Perches
Signed-off-by: Suzuki K Poulose
Link: https://lore.kernel.org/r/20190723221838.12024-5-suzuki.poulose@arm.com
Signed-off-by: Greg Kroah-Hartman
24 May, 2019
1 commit
-
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
Signed-off-by: Greg Kroah-Hartman
25 Apr, 2019
1 commit
-
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
Signed-off-by: Greg Kroah-Hartman
29 Mar, 2019
1 commit
-
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
Cc: Sahara
Cc: stable
Signed-off-by: Greg Kroah-Hartman
28 Mar, 2019
1 commit
-
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
Cc: stable
Signed-off-by: Greg Kroah-Hartman
30 Jan, 2019
1 commit
-
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
Reviewed-by: Theodore Ts'o
Signed-off-by: Greg Kroah-Hartman
22 Jan, 2019
1 commit
-
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
Cc: stable
Signed-off-by: Greg Kroah-Hartman
12 Jan, 2019
1 commit
-
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
Reported-by: Lukas F. Hartmann
Tested-by: Lukas F. Hartmann
Cc: stable
Signed-off-by: Dmitry Safonov
Signed-off-by: Greg Kroah-Hartman
10 Dec, 2018
1 commit
-
We want the TTY changes in here as well.
Signed-off-by: Greg Kroah-Hartman
05 Dec, 2018
3 commits
-
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
Link: lkml.kernel.org/r/
Suggested-by: Jiri Slaby
Reviewed-by: Jiri Slaby
Tested-by: Mark Rutland
Signed-off-by: Dmitry Safonov
Signed-off-by: Greg Kroah-Hartman -
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_forktty_ldisc_reinit() should be called with ldisc_sem hold for writing,
which will protect any reader against line discipline changes.Cc: Jiri Slaby
Cc: stable@vger.kernel.org # b027e2298bd5 ("tty: fix data race between tty_init_dev and flush of buf")
Reviewed-by: Jiri Slaby
Reported-by: syzbot+3aa9784721dfb90e984d@syzkaller.appspotmail.com
Tested-by: Mark Rutland
Tested-by: Tetsuo Handa
Signed-off-by: Dmitry Safonov
Tested-by: Tycho Andersen
Signed-off-by: Greg Kroah-Hartman -
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 # 4.18
Cc: Florian Zumbiehl
Reported-by: Jarkko Nikula
Tested-by: Jarkko Nikula
Acked-by: Greg Kroah-Hartman
Signed-off-by: Johan Hovold
30 Oct, 2018
1 commit
-
Pull tty/serial updates from Greg KH:
"Here is the big tty and serial pull request for 4.20-rc1Lots 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
...
24 Oct, 2018
2 commits
-
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
... -
…iederm/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
...
13 Oct, 2018
4 commits
-
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
-
none of them handles it anyway.
Reviewed-by: Johan Hovold
Signed-off-by: Al Viro -
Signed-off-by: Al Viro
-
Reviewed-by: Johan Hovold
Signed-off-by: Al Viro
12 Oct, 2018
1 commit
-
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: ffffffc06acffad0 x22: ffffff900969e160
[ 20.833232] x21: 0000000000000000 x20: ffffffc06acffac8
[ 20.833559] x19: ffffff900969df90 x18: 0000000000000000
[ 20.833878] x17: 0000000000000000 x16: 0000000000000000
[ 20.834491] x15: ffffffffffffffff x14: ffffffff00000000
[ 20.834821] x13: ffffffffffffffff x12: 0000000000000001
[ 20.835143] x11: 0101010101010101 x10: ffffff880d59ff5f
[ 20.835467] x9 : ffffff880d59ff5e x8 : ffffffc06acffaf3
[ 20.835790] x7 : 0000000000000000 x6 : ffffff880d59ff5f
[ 20.836111] x5 : c06419717c314100 x4 : 0000000000000007
[ 20.836419] x3 : 0000000000000000 x2 : 0000000000000000
[ 20.836732] x1 : 0000000000000001 x0 : ffffff900969df90
[ 20.837100] Process sh (pid: 104, stack limit = 0x(____ptrval____))
[ 20.837396] Call trace:
[ 20.837566] (null)
[ 20.837816] serial8250_set_termios+0x48/0x54
[ 20.838089] uart_set_options+0x138/0x1bc
[ 20.838570] uart_poll_init+0x114/0x16c
[ 20.838834] tty_find_polling_driver+0x158/0x200
[ 20.839119] configure_kgdboc+0xbc/0x1bc
[ 20.839380] param_set_kgdboc_var+0xb8/0x150
[ 20.839658] param_attr_store+0xbc/0x150
[ 20.839920] module_attr_store+0x40/0x58
[ 20.840183] sysfs_kf_write+0x8c/0xa8
[ 20.840183] sysfs_kf_write+0x8c/0xa8
[ 20.840440] kernfs_fop_write+0x154/0x290
[ 20.840702] vfs_write+0xf0/0x278
[ 20.840942] __arm64_sys_write+0x84/0xf4
[ 20.841209] el0_svc_common+0xf4/0x1dc
[ 20.841471] el0_svc_handler+0x98/0xbc
[ 20.841713] el0_svc+0x8/0xc
[ 20.842057] Code: bad PC value
[ 20.842764] ---[ end trace a8835d7de79aaadf ]---
[ 20.843134] Kernel panic - not syncing: Fatal exception
[ 20.843515] SMP: stopping secondary CPUs
[ 20.844289] Kernel Offset: disabled
[ 20.844634] CPU features: 0x0,21806002
[ 20.844857] Memory Limit: none
[ 20.845172] ---[ end Kernel panic - not syncing: Fatal exception ]---Signed-off-by: Miles Chen
Signed-off-by: Greg Kroah-Hartman
18 Sep, 2018
1 commit
-
In case of tty_ldisc_reinit() failure, tty->count should be decremented
back, otherwise we will never release_tty().
Tetsuo reported that it fixes noisy warnings on tty release like:
pts pts4033: tty_release: tty->count(10529) != (#fd's(7) + #kopen's(0))Fixes: commit 892d1fa7eaae ("tty: Destroy ldisc instance on hangup")
Cc: stable@vger.kernel.org # v4.6+
Cc: Greg Kroah-Hartman
Cc: Jiri Slaby
Reviewed-by: Jiri Slaby
Tested-by: Jiri Slaby
Tested-by: Mark Rutland
Tested-by: Tetsuo Handa
Signed-off-by: Dmitry Safonov
Signed-off-by: Greg Kroah-Hartman
16 Sep, 2018
1 commit
-
Replace send_sig and force_sig in __do_SAK with group_send_sig_info
the general helper for sending a signal to a process group. This is
wordier but it allows specifying PIDTYPE_SID so that the signal code
knows the signal went to a session.Both force_sig() and send_sig(..., 1) specify SEND_SIG_PRIV and the
new call of group_send_sig_info does that explicitly. This is enough
to ensure even a pid namespace init is killed.The global init remains unkillable. The guarantee that __do_SAK tries
to provide is a clean path to login to a machine. As the global init is
unkillable, if it chooses to hold open a tty it can violate this
guarantee. A technique other than killing processes would be needed
to provide this guarantee to userspace.The only difference between force_sig and send_sig when sending
SIGKILL is that SIGNAL_UNKILLABLE is cleared. This has no affect on
the processing of a signal sent with SEND_SIG_PRIV by any process, making
it unnecessary, and not behavior that needs to be preserved.force_sig was used originally because it did not take as many locks as
send_sig. Today send_sig, force_sig and group_send_sig_info take the
same locks when delivering a signal.group_send_sig_info also contains a permission check that force_sig
and send_sig do not. However the presence of SEND_SIG_PRIV makes the
permission check a noop. So the permission check does not result
in any behavioral differences.Signed-off-by: "Eric W. Biederman"
14 Sep, 2018
3 commits
-
->set_serial() and ->get_serial() resp., both taking tty and
a kernel pointer to serial_struct.Signed-off-by: Al Viro
-
That code had been live for 11 weeks back in 1992, but it had been 26 years
since sys_ioctl() began handling FIONBIO on its own. Time to to bury the body,
already...Signed-off-by: Al Viro
-
ioctls that are
* callable only via tty_ioctl()
* not driver-specific
* not demand data structure conversions
* either always need passing arg as is or always demand compat_ptr()
get intercepted in tty_compat_ioctl() from the very beginning and
redirecter to tty_ioctl(). As the result, their entries in fs/compat_ioctl.c
(some of those had been missing, BTW) got removed, as well as
n_tty_compat_ioctl_helper() (now it's never called with any cmd it would accept).Signed-off-by: Al Viro