linux.git/drivers/tty/serial/serial_core.c, branch v5.13

serial: core: fix suspicious security_locked_down() call

2021-05-13T15:08:04+00:00

The commit that added this check did so in a very strange way - first
security_locked_down() is called, its value stored into retval, and if
it's nonzero, then an additional check is made for (change_irq ||
change_port), and if this is true, the function returns. However, if
the goto exit branch is not taken, the code keeps the retval value and
continues executing the function. Then, depending on whether
uport->ops->verify_port is set, the retval value may or may not be reset
to zero and eventually the error value from security_locked_down() may
abort the function a few lines below.

I will go out on a limb and assume that this isn't the intended behavior
and that an error value from security_locked_down() was supposed to
abort the function only in case (change_irq || change_port) is true.

Note that security_locked_down() should be called last in any series of
checks, since the SELinux implementation of this hook will do a check
against the policy and generate an audit record in case of denial. If
the operation was to carry on after calling security_locked_down(), then
the SELinux denial record would be bogus.

See commit 59438b46471a ("security,lockdown,selinux: implement SELinux
lockdown") for how SELinux implements this hook.

Fixes: 794edf30ee6c ("lockdown: Lock down TIOCSSERIAL")
Acked-by: Kees Cook 
Signed-off-by: Ondrej Mosnacek 
Cc: stable 
Link: https://lore.kernel.org/r/20210507115719.140799-1-omosnace@redhat.com
Signed-off-by: Greg Kroah-Hartman

serial: core: return early on unsupported ioctls

2021-04-10T08:36:34+00:00

Drivers can return -ENOIOCTLCMD when an ioctl is not recognised to tell
the upper layers to continue looking for a handler.

This is not the case for the RS485 and ISO7816 ioctls whose handlers
should return -ENOTTY directly in case a serial driver does not
implement the corresponding methods.

Fixes: a5f276f10ff7 ("serial_core: Handle TIOC[GS]RS485 ioctls.")
Fixes: ad8c0eaa0a41 ("tty/serial_core: add ISO7816 infrastructure")
Signed-off-by: Johan Hovold 
Link: https://lore.kernel.org/r/20210407095208.31838-9-johan@kernel.org
Signed-off-by: Greg Kroah-Hartman

serial: core: drop redundant TIOCGSERIAL memset

2021-04-10T08:36:34+00:00

Since commit 5099d234a52a ("serial_core: switch to ->[sg]et_serial()")
the serial structure passed to uart_get_info() has already have been
cleared by the tty layer so drop the redundant memset.

Signed-off-by: Johan Hovold 
Link: https://lore.kernel.org/r/20210407095208.31838-8-johan@kernel.org
Signed-off-by: Greg Kroah-Hartman

serial: core: Remove BUG_ON(in_interrupt()) check

2021-02-09T10:45:04+00:00

The usage of in_interrupt() in drivers is phased out for various
reasons.

In both exported functions where BUG_ON(in_interrupt()) is invoked,
there is a mutex_lock() afterwards. mutex_lock() contains a
might_sleep() which will already trigger a stack trace if the target
functions is called from atomic context.

Remove the BUG_ON() and add a "Context: " in the kernel-doc instead.

Signed-off-by: Ahmed S. Darwish 
Signed-off-by: Sebastian Andrzej Siewior 
Link: https://lore.kernel.org/r/20210208181615.381861-3-bigeasy@linutronix.de
Signed-off-by: Greg Kroah-Hartman

tty_port: drop last traces of low_latency

2021-01-07T15:17:32+00:00

The main purpose of tty_port::low_latency was removed in commit
a9c3f68f3cd8 (tty: Fix low_latency BUG) back in 2014. It was left in
place for drivers as an optional tune knob. But only one driver has been
using it until the previous commit. So remove this misconcept
completely, given there are no users.

Signed-off-by: Jiri Slaby 
Link: https://lore.kernel.org/r/20210105120239.28031-11-jslaby@suse.cz
Signed-off-by: Greg Kroah-Hartman

serial_core: Check for port state when tty is in error state

2020-12-09T14:34:37+00:00

At the moment opening a serial device node (such as /dev/ttyS3)
succeeds even if there is no actual serial device behind it.
Reading/writing/ioctls fail as expected because the uart port is not
initialized (the type is PORT_UNKNOWN) and the TTY_IO_ERROR error state
bit is set fot the tty.

However setting line discipline does not have these checks
8250_port.c (8250 is the default choice made by univ8250_console_init()).
As the result of PORT_UNKNOWN, uart_port::iobase is NULL which
a platform translates onto some address accessing which produces a crash
like below.

This adds tty_port_initialized() to uart_set_ldisc() to prevent the crash.

Found by syzkaller.

Signed-off-by: Alexey Kardashevskiy 
Link: https://lore.kernel.org/r/20201203055834.45838-1-aik@ozlabs.ru
Cc: stable 
Signed-off-by: Greg Kroah-Hartman

Merge 5.9.0-rc6 into tty-next

2020-09-21T07:23:55+00:00

We need the tty/serial fixes in here and this resolves a merge issue in
the 8250 driver.

Signed-off-by: Greg Kroah-Hartman

serial: core: fix console port-lock regression

2020-09-16T11:22:44+00:00

Fix the port-lock initialisation regression introduced by commit
a3cb39d258ef ("serial: core: Allow detach and attach serial device for
console") by making sure that the lock is again initialised during
console setup.

The console may be registered before the serial controller has been
probed in which case the port lock needs to be initialised during
console setup by a call to uart_set_options(). The console-detach
changes introduced a regression in several drivers by effectively
removing that initialisation by not initialising the lock when the port
is used as a console (which is always the case during console setup).

Add back the early lock initialisation and instead use a new
console-reinit flag to handle the case where a console is being
re-attached through sysfs.

The question whether the console-detach interface should have been added
in the first place is left for another discussion.

Note that the console-enabled check in uart_set_options() is not
redundant because of kgdboc, which can end up reinitialising an already
enabled console (see commit 42b6a1baa3ec ("serial_core: Don't
re-initialize a previously initialized spinlock.")).

Fixes: a3cb39d258ef ("serial: core: Allow detach and attach serial device for console")
Cc: stable      # 5.7
Signed-off-by: Johan Hovold 
Reviewed-by: Andy Shevchenko 
Link: https://lore.kernel.org/r/20200909143101.15389-3-johan@kernel.org
Signed-off-by: Greg Kroah-Hartman

serial: core: fix port-lock initialisation

2020-09-16T11:22:10+00:00

Commit f743061a85f5 ("serial: core: Initialise spin lock before use in
uart_configure_port()") tried to work around a breakage introduced by
commit a3cb39d258ef ("serial: core: Allow detach and attach serial
device for console") by adding a second initialisation of the port lock
when registering the port.

As reported by the build robots [1], this doesn't really solve the
regression introduced by the console-detach changes and also adds a
second redundant initialisation of the lock for normal ports.

Start cleaning up this mess by removing the redundant initialisation and
making sure that the port lock is again initialised once-only for ports
that aren't already in use as a console.

[1] https://lore.kernel.org/r/20200802054852.GR23458@shao2-debian

Fixes: f743061a85f5 ("serial: core: Initialise spin lock before use in uart_configure_port()")
Fixes: a3cb39d258ef ("serial: core: Allow detach and attach serial device for console")
Cc: stable      # 5.7
Signed-off-by: Johan Hovold 
Reviewed-by: Andy Shevchenko 
Link: https://lore.kernel.org/r/20200909143101.15389-2-johan@kernel.org
Signed-off-by: Greg Kroah-Hartman

serial: core: Simplify with dev_err_probe()

2020-09-04T15:14:31+00:00

Common pattern of handling deferred probe can be simplified with
dev_err_probe().  Less code and the error value gets printed.

Signed-off-by: Krzysztof Kozlowski 
Reviewed-by: Lukas Wunner 
Link: https://lore.kernel.org/r/20200901153100.18827-2-krzk@kernel.org
Signed-off-by: Greg Kroah-Hartman