When support for various old platforms was removed in commit
1ea35b3557 ("ARM: s3c: remove s3c24xx specific hacks"),
s3c24xx_serial_ops also became unused here because nothing sets port
type TYPE_S3C24XX anymore.
Remove s3c24xx_serial_ops and all the code that's unreachable now.
Fixes: 1ea35b3557 ("ARM: s3c: remove s3c24xx specific hacks")
Signed-off-by: André Draszik <andre.draszik@linaro.org>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org>
Link: https://lore.kernel.org/r/20231019100901.4026680-1-andre.draszik@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tabs were used in the function description, to make this look more
uniform, the tabs were replaced by spaces where necessary.
While we're at it, I also replaced the 'ndashes' with simple dashes, since
only those are supported by sphinx.
Reviewed-by: Jiri Slaby <jirislaby@kernel.org>
Signed-off-by: Florian Eckert <fe@dev.tdt.de>
Link: https://lore.kernel.org/r/20231019112809.881730-2-fe@dev.tdt.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
esp32s3 variant of the esp32 UART has limited baudrate divisor range
that does not allow it to use 9600 and lower rates with 40MHz input
clock. Use clock prescaler present in this UART variant to help with
that.
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Link: https://lore.kernel.org/r/20231018191252.1551972-1-jcmvbkbc@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
uart_get_baud_rate has input parameters 'min' and 'max' limiting the
range of acceptable baud rates from the caller's perspective. If neither
current or old termios structures have acceptable baud rate setting and
9600 is not in the min/max range either the function returns 0 and
issues a warning.
However for a UART that does not support speed of 9600 baud this is
expected behavior.
Clarify that 0 can be (and always could be) returned from the
uart_get_baud_rate. Don't issue a warning in that case.
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Link: https://lore.kernel.org/r/20231010085926.1021667-2-jcmvbkbc@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Zynq UG585 states, in chapter B.33, for XUARTPS_CR_STARTBRK:
It can only be set if STPBRK (Stop transmitter break) is not high
This fixes tcsendbreak, which otherwise does not actually break.
Signed-Off-By: Julien Malik <julien.malik@unseenlabs.fr>
Link: https://lore.kernel.org/r/20230624210323.88455-1-julien.malik@unseenlabs.fr
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
We need the tty/serial fixes in here as well for testing, and this
resolves merge conflicts in:
drivers/tty/serial/serial_core.c
as reported in linux-next
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The smp_processor_id() shouldn't be called from preemptible code.
Instead use get_cpu() and put_cpu() which disables preemption in
addition to getting the processor id. Enable preemption back after
calling schedule_work() to make sure that the work gets scheduled on all
cores other than the current core. We want to avoid a scenario where
current core's stack trace is printed multiple times and one core's
stack trace isn't printed because of scheduling of current task.
This fixes the following bug:
[ 119.143590] sysrq: Show backtrace of all active CPUs
[ 119.143902] BUG: using smp_processor_id() in preemptible [00000000] code: bash/873
[ 119.144586] caller is debug_smp_processor_id+0x20/0x30
[ 119.144827] CPU: 6 PID: 873 Comm: bash Not tainted 5.10.124-dirty #3
[ 119.144861] Hardware name: QEMU QEMU Virtual Machine, BIOS 2023.05-1 07/22/2023
[ 119.145053] Call trace:
[ 119.145093] dump_backtrace+0x0/0x1a0
[ 119.145122] show_stack+0x18/0x70
[ 119.145141] dump_stack+0xc4/0x11c
[ 119.145159] check_preemption_disabled+0x100/0x110
[ 119.145175] debug_smp_processor_id+0x20/0x30
[ 119.145195] sysrq_handle_showallcpus+0x20/0xc0
[ 119.145211] __handle_sysrq+0x8c/0x1a0
[ 119.145227] write_sysrq_trigger+0x94/0x12c
[ 119.145247] proc_reg_write+0xa8/0xe4
[ 119.145266] vfs_write+0xec/0x280
[ 119.145282] ksys_write+0x6c/0x100
[ 119.145298] __arm64_sys_write+0x20/0x30
[ 119.145315] el0_svc_common.constprop.0+0x78/0x1e4
[ 119.145332] do_el0_svc+0x24/0x8c
[ 119.145348] el0_svc+0x10/0x20
[ 119.145364] el0_sync_handler+0x134/0x140
[ 119.145381] el0_sync+0x180/0x1c0
Cc: jirislaby@kernel.org
Cc: stable@vger.kernel.org
Fixes: 47cab6a722 ("debug lockups: Improve lockup detection, fix generic arch fallback")
Signed-off-by: Muhammad Usama Anjum <usama.anjum@collabora.com>
Link: https://lore.kernel.org/r/20231009162021.3607632-1-usama.anjum@collabora.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The new Amlogic S4 SoC does not have a always-on uart, so add
OF_EARLYCON_DECLARE for it.
Amlogic T7 will use this as fallback.
Signed-off-by: Lucas Tanure <tanure@linux.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://lore.kernel.org/r/20231009121151.4509-1-tanure@linux.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Maximilian reported that surface_serial_hub serdev tx does not work during
system suspend. During system suspend, runtime PM gets disabled in
__device_suspend_late(), and tx is unable to wake-up the serial core port
device that we use to check if tx is safe to start. Johan summarized the
regression noting that serdev tx no longer always works as earlier when the
serdev device is runtime PM active.
The serdev device and the serial core controller devices are siblings of
the serial port hardware device. The runtime PM usage count from serdev
device does not propagate to the serial core device siblings, it only
propagates to the parent.
In addition to the tx issue for suspend, testing for the serial core port
device can cause an unnecessary delay in enabling tx while waiting for the
serial core port device to wake-up. The serial core port device wake-up is
only needed to flush pending tx when the serial port hardware device was
in runtime PM suspended state.
To fix the regression, we need to check the runtime PM state of the parent
serial port hardware device for tx instead of the serial core port device.
As the serial port device drivers may or may not implement runtime PM, we
need to also add a check for pm_runtime_enabled().
Reported-by: Maximilian Luz <luzmaximilian@gmail.com>
Cc: stable <stable@kernel.org>
Fixes: 84a9582fd2 ("serial: core: Start managing serial controllers to enable runtime PM")
Signed-off-by: Tony Lindgren <tony@atomide.com>
Tested-by: Maximilian Luz <luzmaximilian@gmail.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20231005075644.25936-1-tony@atomide.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
If this check ever triggers
static int uart_get_info(struct tty_port *port, struct serial_struct *retinfo)
{
uport = uart_port_check(state);
if (!uport)
goto out;
then all those sysfs users will print stack contents to userspace.
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Link: https://lore.kernel.org/r/967b9ef1-fb36-48bf-9e6a-1b99af24c052@p183
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Now that the driver core allows for struct class to be in read-only
memory, making all 'class' structures to be declared at build time
placing them into read-only memory, instead of having to be dynamically
allocated at load time.
Cc: Jiri Slaby <jirislaby@kernel.org>
Link: https://lore.kernel.org/r/2023100549-sixth-anger-ac34@gregkh
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Now that the driver core allows for struct class to be in read-only
memory, making all 'class' structures to be declared at build time
placing them into read-only memory, instead of having to be dynamically
allocated at load time.
Cc: Jiri Slaby <jirislaby@kernel.org>
Link: https://lore.kernel.org/r/2023100546-humbly-prologue-e58c@gregkh
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
TIOCLINUX can be used for privilege escalation on virtual terminals when
code is executed via tools like su/sudo and sandboxing tools.
By abusing the selection features, a lower-privileged application can
write content to the console, select and copy/paste that content and
thereby executing code on the privileged account. See also the poc
here:
https://www.openwall.com/lists/oss-security/2023/03/14/3
Selection is usually used by tools like gpm that provide mouse features
on the virtual console. gpm already runs as root (due to earlier
changes that restrict access to a user on the current TTY), therefore
it will still work with this change.
With this change, the following TIOCLINUX subcommands require
CAP_SYS_ADMIN:
* TIOCL_SETSEL - setting the selected region on the terminal
* TIOCL_PASTESEL - pasting the contents of the selected region into
the input buffer
* TIOCL_SELLOADLUT - changing word-by-word selection behaviour
The security problem mitigated is similar to the security risks caused
by TIOCSTI, which, since kernel 6.2, can be disabled with
CONFIG_LEGACY_TIOCSTI=n.
Signed-off-by: Hanno Böck <hanno@hboeck.de>
Signed-off-by: Günther Noack <gnoack@google.com>
Tested-by: Günther Noack <gnoack@google.com>
Link: https://lore.kernel.org/r/20230828164117.3608812-2-gnoack@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Simplify uart_get_rs485_mode() by using temporary variable for
the GPIO descriptor. With that, use proper type for the flags
of the GPIO descriptor.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20231003142346.3072929-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Let's drop the use of pm_runtime_irq_safe() for 8250_omap. The use of
pm_runtime_irq_safe() is not nice as it takes a permanent usage count on
the parent device.
We can finally drop pm_runtime_irq_safe() safely as the kernel now knows
when the uart port tx is active. This changed with commit 84a9582fd2
("serial: core: Start managing serial controllers to enable runtime PM").
For serial port rx, we already use Linux generic wakeirqs for 8250_omap.
To drop pm_runtime_irq_safe(), we need to add handling for shallow idle
state where the port hardware may already be awake and an IO interrupt
happens. We also need to replace the serial8250_rpm sync calls in the
interrupt handlers with async runtime PM calls.
Note that omap8250_irq() calls omap_8250_dma_handle_irq(), so we don't
need separate runtime PM calls in omap_8250_dma_handle_irq().
While at it, let's also add the missing line break to the end of
omap8250_runtime_resume() to group the calls.
Signed-off-by: Tony Lindgren <tony@atomide.com>
Link: https://lore.kernel.org/r/20231004062650.64487-1-tony@atomide.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
We now get errors on system suspend if no_console_suspend is set as
reported by Thomas. The errors started with commit 20a41a6261 ("serial:
8250_omap: Use force_suspend and resume for system suspend").
Let's fix the issue by checking for console_suspend_enabled in the system
suspend and resume path.
Note that with this fix the checks for console_suspend_enabled in
omap8250_runtime_suspend() become useless. We now keep runtime PM usage
count for an attached kernel console starting with commit bedb404e91
("serial: 8250_port: Don't use power management for kernel console").
Fixes: 20a41a6261 ("serial: 8250_omap: Use force_suspend and resume for system suspend")
Cc: stable <stable@kernel.org>
Cc: Udit Kumar <u-kumar1@ti.com>
Reported-by: Thomas Richard <thomas.richard@bootlin.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Tested-by: Thomas Richard <thomas.richard@bootlin.com>
Reviewed-by: Dhruva Gole <d-gole@ti.com>
Link: https://lore.kernel.org/r/20230926061319.15140-1-tony@atomide.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Commit 44b27aec9d ("serial: core, 8250: set RS485 termination GPIO in
serial core") enabled support for RS485 termination GPIOs behind i2c
expanders by setting the GPIO outside of the critical section protected
by the port spinlock. Access to the i2c expander may sleep, which
caused a splat with the port spinlock held.
Commit 7c7f9bc986 ("serial: Deassert Transmit Enable on probe in
driver-specific way") erroneously regressed that by spinlocking the
GPIO manipulation again.
Fix by moving uart_rs485_config() (the function manipulating the GPIO)
outside of the spinlocked section and acquiring the spinlock inside of
uart_rs485_config() for the invocation of ->rs485_config() only.
This gets us one step closer to pushing the spinlock down into the
->rs485_config() callbacks which actually need it. (Some callbacks
do not want to be spinlocked because they perform sleepable register
accesses, see e.g. sc16is7xx_config_rs485().)
Stack trace for posterity:
Voluntary context switch within RCU read-side critical section!
WARNING: CPU: 0 PID: 56 at kernel/rcu/tree_plugin.h:318 rcu_note_context_switch
Call trace:
rcu_note_context_switch
__schedule
schedule
schedule_timeout
wait_for_completion_timeout
bcm2835_i2c_xfer
__i2c_transfer
i2c_transfer
i2c_transfer_buffer_flags
regmap_i2c_write
_regmap_raw_write_impl
_regmap_bus_raw_write
_regmap_write
_regmap_update_bits
regmap_update_bits_base
pca953x_gpio_set_value
gpiod_set_raw_value_commit
gpiod_set_value_nocheck
gpiod_set_value_cansleep
uart_rs485_config
uart_add_one_port
pl011_register_port
pl011_probe
Fixes: 7c7f9bc986 ("serial: Deassert Transmit Enable on probe in driver-specific way")
Suggested-by: Lino Sanfilippo <LinoSanfilippo@gmx.de>
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Cc: stable@vger.kernel.org # v6.1+
Link: https://lore.kernel.org/r/f3a35967c28b32f3c6432d0aa5936e6a9908282d.1695307688.git.lukas@wunner.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Convert driver to be property provider agnostic and allow it to be
used on non-OF platforms.
Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
Link: https://lore.kernel.org/r/20230927160153.2717788-2-hugo@hugovil.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Many SoCs do not integrate DMA for the amba pl011 UART, causing
the following message on boot:
uart-pl011 80074000.serial: no DMA platform data
The UART still works in PIO, so better not to print such message that
may confuse people by causing them to think that there is something wrong
with the UART.
Change the message to debug level.
Signed-off-by: Fabio Estevam <festevam@denx.de>
Link: https://lore.kernel.org/r/20230928145842.466933-1-festevam@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Lockdep complains about possible circular locking dependencies when the
i.MX SDMA driver issues console messages under its spinlock. While the
SDMA driver calls back into the UART when issuing a message, the i.MX
UART driver will never call back into the SDMA driver for this UART,
because DMA is explicitly not used for UARTs providing the console.
To avoid the lockdep warnings put the UART port lock for console devices
into a separate subclass.
This fixes possible deadlock warnings like the following which was
provoked by adding a printk to the i.MX SDMA driver at a place where the
driver holds its spinlock.
======================================================
WARNING: possible circular locking dependency detected
6.6.0-rc3-00045-g517852be693b-dirty #110 Not tainted
------------------------------------------------------
swapper/0/0 is trying to acquire lock:
c1818e04 (console_owner){-...}-{0:0}, at: console_flush_all+0x1c4/0x634
but task is already holding lock:
c44649e0 (&vc->lock){-...}-{3:3}, at: sdma_int_handler+0xc4/0x368
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 (&vc->lock){-...}-{3:3}:
_raw_spin_lock_irqsave+0x4c/0x68
sdma_prep_dma_cyclic+0x1a8/0x21c
imx_uart_startup+0x44c/0x5d4
uart_startup+0x120/0x2b0
uart_port_activate+0x44/0x98
tty_port_open+0x80/0xd0
uart_open+0x18/0x20
tty_open+0x120/0x664
chrdev_open+0xc0/0x214
do_dentry_open+0x1d0/0x544
path_openat+0xbb0/0xea0
do_filp_open+0x5c/0xd4
do_sys_openat2+0xb8/0xf0
sys_openat+0x8c/0xd8
ret_fast_syscall+0x0/0x1c
-> #1 (&port_lock_key){-.-.}-{3:3}:
_raw_spin_lock_irqsave+0x4c/0x68
imx_uart_console_write+0x164/0x1a0
console_flush_all+0x220/0x634
console_unlock+0x64/0x164
vprintk_emit+0xb0/0x390
vprintk_default+0x24/0x2c
_printk+0x2c/0x5c
register_console+0x244/0x478
serial_core_register_port+0x5c4/0x618
imx_uart_probe+0x4e0/0x7d4
platform_probe+0x58/0xb0
really_probe+0xc4/0x2e0
__driver_probe_device+0x84/0x1a0
driver_probe_device+0x2c/0x108
__driver_attach+0x94/0x17c
bus_for_each_dev+0x7c/0xd0
bus_add_driver+0xc4/0x1cc
driver_register+0x7c/0x114
imx_uart_init+0x20/0x40
do_one_initcall+0x7c/0x3c4
kernel_init_freeable+0x17c/0x228
kernel_init+0x14/0x140
ret_from_fork+0x14/0x24
-> #0 (console_owner){-...}-{0:0}:
__lock_acquire+0x14b0/0x29a0
lock_acquire.part.0+0xb4/0x264
console_flush_all+0x20c/0x634
console_unlock+0x64/0x164
vprintk_emit+0xb0/0x390
vprintk_default+0x24/0x2c
_printk+0x2c/0x5c
sdma_int_handler+0xcc/0x368
__handle_irq_event_percpu+0x94/0x2d0
handle_irq_event+0x38/0xd0
handle_fasteoi_irq+0x98/0x248
handle_irq_desc+0x1c/0x2c
gic_handle_irq+0x6c/0x90
generic_handle_arch_irq+0x2c/0x64
__irq_svc+0x90/0xbc
cpuidle_enter_state+0x1a0/0x4f4
cpuidle_enter+0x30/0x40
do_idle+0x210/0x2b4
cpu_startup_entry+0x28/0x2c
rest_init+0xd0/0x184
arch_post_acpi_subsys_init+0x0/0x8
other info that might help us debug this:
Chain exists of:
console_owner --> &port_lock_key --> &vc->lock
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&vc->lock);
lock(&port_lock_key);
lock(&vc->lock);
lock(console_owner);
*** DEADLOCK ***
3 locks held by swapper/0/0:
#0: c44649e0 (&vc->lock){-...}-{3:3}, at: sdma_int_handler+0xc4/0x368
#1: c1818d50 (console_lock){+.+.}-{0:0}, at: vprintk_default+0x24/0x2c
#2: c1818d08 (console_srcu){....}-{0:0}, at: console_flush_all+0x44/0x634
stack backtrace:
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.6.0-rc3-00045-g517852be693b-dirty #110
Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
unwind_backtrace from show_stack+0x10/0x14
show_stack from dump_stack_lvl+0x60/0x90
dump_stack_lvl from check_noncircular+0x184/0x1b8
check_noncircular from __lock_acquire+0x14b0/0x29a0
__lock_acquire from lock_acquire.part.0+0xb4/0x264
lock_acquire.part.0 from console_flush_all+0x20c/0x634
console_flush_all from console_unlock+0x64/0x164
console_unlock from vprintk_emit+0xb0/0x390
vprintk_emit from vprintk_default+0x24/0x2c
vprintk_default from _printk+0x2c/0x5c
_printk from sdma_int_handler+0xcc/0x368
sdma_int_handler from __handle_irq_event_percpu+0x94/0x2d0
__handle_irq_event_percpu from handle_irq_event+0x38/0xd0
handle_irq_event from handle_fasteoi_irq+0x98/0x248
handle_fasteoi_irq from handle_irq_desc+0x1c/0x2c
handle_irq_desc from gic_handle_irq+0x6c/0x90
gic_handle_irq from generic_handle_arch_irq+0x2c/0x64
generic_handle_arch_irq from __irq_svc+0x90/0xbc
Exception stack(0xc1801ee8 to 0xc1801f30)
1ee0: ffffffff ffffffff 00000001 00030349 00000000 00000012
1f00: 00000000 d7e45f4b 00000012 00000000 d7e16d63 c1810828 00000000 c1801f38
1f20: c108125c c1081260 60010013 ffffffff
__irq_svc from cpuidle_enter_state+0x1a0/0x4f4
cpuidle_enter_state from cpuidle_enter+0x30/0x40
cpuidle_enter from do_idle+0x210/0x2b4
do_idle from cpu_startup_entry+0x28/0x2c
cpu_startup_entry from rest_init+0xd0/0x184
rest_init from arch_post_acpi_subsys_init+0x0/0x8
Reported-by: Tim van der Staaij <Tim.vanderstaaij@zigngroup.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Link: https://lore.kernel.org/r/20230928064320.711603-1-s.hauer@pengutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Prepare for the coming implementation by GCC and Clang of the __counted_by
attribute. Flexible array members annotated with __counted_by can have
their accesses bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS
(for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family
functions).
As found with Coccinelle[1], add __counted_by for struct pci1xxxx_8250.
[1] https://github.com/kees/kernel-tools/blob/trunk/coccinelle/examples/counted_by.cocci
Cc: Kumaravel Thiagarajan <kumaravel.thiagarajan@microchip.com>
Cc: Tharun Kumar P <tharunkumar.pasumarthi@microchip.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Jiri Slaby <jirislaby@kernel.org>
Cc: linux-serial@vger.kernel.org
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: "Gustavo A. R. Silva" <gustavoars@kernel.org>
Link: https://lore.kernel.org/r/20230922175242.work.442-kees@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sealevel XR17V35X based cards utilize DTR to control RS-485 Enable, but
the current implementation of 8250_exar uses RTS for the auto-RS485-Enable
mode of the XR17V35X UARTs. This patch implements DTR Auto-RS485 on
Sealevel cards.
Signed-off-by: Matthew Howell <matthew.howell@sealevel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenkoa@linux.intel.com>
Link: https://lore.kernel.org/r/4b8ad8ab6728742464c4e048fdeecb2b40522aef.camel@sealevel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
strlcpy() reads the entire source buffer first and returns the size of
the source string, not the destination string, which can be accidentally
misused [1].
The copy_to_user() call uses @len returned from strlcpy() directly
without checking its value. This could potentially lead to read
overflow. There is no existing bug since @len is always guaranteed to be
greater than hardcoded strings in @func_table[kb_func]. But as written
it is very fragile and specifically uses a strlcpy() result without sanity
checking and using it to copy to userspace.
In an effort to remove strlcpy() completely [2], replace
strlcpy() here with strscpy().
[1] https://www.kernel.org/doc/html/latest/process/deprecated.html#strlcpy
[2] https://github.com/KSPP/linux/issues/89
Signed-off-by: Azeem Shaikh <azeems@google.com>
Reviewed-by: Justin Stitt <justinstitt@google.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20230919192156.121503-1-azeems@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Prepare for the coming implementation by GCC and Clang of the __counted_by
attribute. Flexible array members annotated with __counted_by can have
their accesses bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS
(for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family
functions).
As found with Coccinelle[1], add __counted_by for struct mxser_board.
[1] https://github.com/kees/kernel-tools/blob/trunk/coccinelle/examples/counted_by.cocci
Cc: Jiri Slaby <jirislaby@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: NXP Linux Team <linux-imx@nxp.com>
Cc: linux-serial@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Jiri Slaby <jirislaby@kernel.org>
Reviewed-by: "Gustavo A. R. Silva" <gustavoars@kernel.org>
Link: https://lore.kernel.org/r/20230922175245.work.196-kees@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Use devm_clk_get_optional_enabled() to simplify the code.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Link: https://lore.kernel.org/r/20230919195513.3197930-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Now, the "jumped-over" code is simple enough to be put inside an 'if'.
Do so to make it 'goto'-less.
Signed-off-by: "Jiri Slaby (SUSE)" <jirislaby@kernel.org>
Link: https://lore.kernel.org/r/20230919085156.1578-16-jirislaby@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
msleep_interruptible() will check on its own. So no need to do the check
in send_break() before calling the above.
Signed-off-by: "Jiri Slaby (SUSE)" <jirislaby@kernel.org>
Link: https://lore.kernel.org/r/20230919085156.1578-15-jirislaby@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
If the driver sets TTY_DRIVER_HARDWARE_BREAK, we leave ops->break_ctl()
to the driver and return from send_break(). But we do it using a local
variable and keep the code flowing through the end of the function.
Instead, do 'return' immediately with the ops->break_ctl()'s return
value.
This way, we don't have to stuff the 'else' branch of the 'if' with the
software break handling. And we can re-indent the function too.
Signed-off-by: "Jiri Slaby (SUSE)" <jirislaby@kernel.org>
Link: https://lore.kernel.org/r/20230919085156.1578-14-jirislaby@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
And make an explicit constant for zero too. This allows for easier type
checking of the parameter.
Note: tty_struct::flow_change is kept as int because include/tty.h
(tty_struct) doesn't see tty/tty.h (this enum).
Signed-off-by: "Jiri Slaby (SUSE)" <jirislaby@kernel.org>
Link: https://lore.kernel.org/r/20230919085156.1578-13-jirislaby@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
An ndash used instead of a single dash renders a bullet to the result.
So use only single dashes in kernel-doc.
Signed-off-by: "Jiri Slaby (SUSE)" <jirislaby@kernel.org>
Link: https://lore.kernel.org/r/20230919085156.1578-11-jirislaby@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The ioctl helpers are well documented, except they are not plugged in
the Documentation. So fix up the minor issues in the kernel-doc and plug
it in.
The minor issues include:
* bad \t on every line (sphinx misinterprets the description otherwise)
* missing colon after Return
* superfluous \n after the comment
* make some struct members and constants a hyperlink
* and so on
Perhaps better to use --word-diff if one wants to see the "real"
changes.
Signed-off-by: "Jiri Slaby (SUSE)" <jirislaby@kernel.org>
Link: https://lore.kernel.org/r/20230919085156.1578-9-jirislaby@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
If tty_{,un}throttle_safe() returned true on success (similar to
*_trylock()), it would make the conditions in callers more obvious. So
perform the switch to these inverted values (and fix the callers).
Signed-off-by: "Jiri Slaby (SUSE)" <jirislaby@kernel.org>
Link: https://lore.kernel.org/r/20230919085156.1578-8-jirislaby@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
They return 0 or 1 -- a boolean value, so make it clear than noone
should expect negative or other values.
Signed-off-by: "Jiri Slaby (SUSE)" <jirislaby@kernel.org>
Link: https://lore.kernel.org/r/20230919085156.1578-7-jirislaby@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This change gets rid of the complicated exit from the loops. It can be
done much easier using do-while loops.
Signed-off-by: "Jiri Slaby (SUSE)" <jirislaby@kernel.org>
Link: https://lore.kernel.org/r/20230919085156.1578-6-jirislaby@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Make "no numbers available" a fast quit from the function. And do the
heavy work outside the 'if'. This makes the code more understandable and
conforming to the common kernel coding style.
Signed-off-by: "Jiri Slaby (SUSE)" <jirislaby@kernel.org>
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Link: https://lore.kernel.org/r/20230919085156.1578-5-jirislaby@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
n is a minimum of:
* available chars in the ring buffer
* available chars in the ring buffer till the end of the ring buffer
* requested number (*nr)
We can use min3() for that instead of two min()s.
Signed-off-by: "Jiri Slaby (SUSE)" <jirislaby@kernel.org>
Link: https://lore.kernel.org/r/20230919085156.1578-4-jirislaby@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The value stored to the current 'retval' is number of characters. It is
both obtained and put to user as unsigned. So make its type unsigned.
And provided it's not a "return value" per se, rename it to 'num'.
Signed-off-by: "Jiri Slaby (SUSE)" <jirislaby@kernel.org>
Link: https://lore.kernel.org/r/20230919085156.1578-3-jirislaby@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
In n_tty_read(), there is a separate int variable 'c' and is used only
to hold an int value returned from job_control(). There is also a
'retval' variable typed ssize_t. So drop this single occurrence of 'c'
and reuse 'retval' which is used on all other places to hold the value
returned from n_tty_read().
Note that 'retval' needs not be initialized now. Drop that.
Signed-off-by: "Jiri Slaby (SUSE)" <jirislaby@kernel.org>
Link: https://lore.kernel.org/r/20230919085156.1578-2-jirislaby@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Make the error messages format unified by switching to use
dev_err_probe() where it makes sense.
This also helps simplifing the code.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
Link: https://lore.kernel.org/r/20230918103648.1185663-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
