recv_dless_read() receives a P_DATA_REPLY from a peer into the bio of an
outstanding read request. The peer-supplied payload length reaches it as
the signed int data_size, and two peer-controlled inputs can make it
negative. With a negotiated data-integrity-alg the digest length is
subtracted first, so a reply whose payload is smaller than the digest
underflows data_size. With no integrity algorithm (the default) data_size
is assigned from the unsigned h95/h100 wire length and drbdd() never
bounds it for a payload-carrying command, so a length above INT_MAX casts
it negative; this path needs no non-default feature. The bio receive loop
then computes expect = min_t(int, data_size, bv_len), which is negative,
and drbd_recv_all_warn(mapped, expect) receives with a size_t of SIZE_MAX
into the first mapped page.
The sibling receive path read_in_block() is not affected: it uses an
unsigned size and rejects it against DRBD_MAX_BIO_SIZE before receiving.
Reject a data reply whose size is negative after the optional digest
subtraction, covering both triggers.
Impact: a malicious or man-in-the-middle DRBD peer copies attacker-chosen
bytes past a bio page in the receiver, corrupting kernel memory. A node
that reads from its peer (a diskless node, or read-balancing to the peer)
is exposed in the default configuration; data-integrity-alg is not
required.
Fixes: b411b3637f ("The DRBD driver")
Cc: stable@vger.kernel.org
Assisted-by: Codex:gpt-5-5-xhigh
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com>
Reviewed-by: Christoph Böhmwalder <christoph.boehmwalder@linbit.com>
Link: https://patch.msgid.link/20260710022837.3738461-1-michael.bommarito@gmail.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
If no_console_suspend is specified, on suspend the 8250 console driver
uses a scratch register (UART_SCR) to store a special canary value. This
is used during the resume path to identify a printk() call before the
driver's own ->resume() callback. In this case,
serial8250_console_restore() is called to quickly re-init the 8250 for
console printing.
See commit 4516d50aab ("serial: 8250: Use canary to restart console after
suspend") for the original motivation.
Unfortunately, this canary workaround does not work in all cases (such as
suspend to mem) because the scratch register will not reset. This has not
been a real issue until now because it could simply lead to some garbage
characters upon resume. However, with the introduction of console flow
control it becomes a real problem because a failed suspend/resume detection
when flow control is enabled leads to all characters hitting the flow
control timeout.
Workaround this issue by temporarily ignoring console flow control when
the debug canary suspend/resume detection is active.
Fixes: 5e6dfb87b1 ("serial: 8250: Add support for console flow control")
Signed-off-by: John Ogness <john.ogness@linutronix.de>
Link: https://patch.msgid.link/20260707141032.5074-1-john.ogness@linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
In accordance with Errata (specification updates)
HSUART May Stop Functioning when DMA is Active.
- Denverton document #572409, rev 3.4, DNV60
- Ice Lake Xeon D document #714070, ICXD65
- Snowridge document #731931, SNR44
For a quick fix just disable the respective callbacks during the device probe.
Depending on the future development we might remove them completely.
Reported-by: micas-opensource <zjianan156@gmail.com>
Closes: https://lore.kernel.org/linux-serial/20250625031409.2404219-1-opensource@ruijie.com.cn/
Fixes: 6ede6dcd87 ("serial: 8250_mid: add support for DMA engine handling from UART MMIO")
Cc: stable <stable@kernel.org>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://patch.msgid.link/20260626094937.561776-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
On AM33xx RX DMA only triggers when the FIFO reaches the
configured threshold (typically 48 bytes). For smaller bursts
no DMA request is issued and the FIFO is drained by RX timeout.
In this case __dma_rx_do_complete() can legitimately see count == 0.
The current code exits early in this case and does not clear
dma->rx_running, leaving the DMA state inconsistent. This can
prevent RX DMA from restarting and may cause
omap_8250_rx_dma_flush() to fail, marking DMA as broken.
Fix this by clearing dma->rx_running once the DMA transfer has
completed or been terminated, even if no data was transferred.
Fixes: a5fd8945a4 ("serial: 8250: 8250_omap.c: Clear DMA RX running status only after DMA termination is done")
Cc: stable <stable@kernel.org>
Signed-off-by: Matthias Feser <mfe@KBSgmbhfr.onmicrosoft.com>
Reviewed-by: Moteen Shah <m-shah@ti.com>
Link: https://patch.msgid.link/BE3P281MB55155F2F5795E411F5A65282EE0B2@BE3P281MB5515.DEUP281.PROD.OUTLOOK.COM
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
csi_modifier_param() builds the xterm modifier parameter from
shift_state, counting KG_SHIFTL/KG_SHIFTR as Shift, KG_ALTGR as Alt
and KG_CTRLL/KG_CTRLR as Ctrl in addition to the canonical KG_SHIFT,
KG_ALT and KG_CTRL.
That is wrong when those weights are not plain modifiers. Keymaps
derived from XKB layouts (by kbd's xkbsupport, and by the
console-setup used in Debian, Ubuntu and others) encode the active
layout group using KG_SHIFTL/KG_SHIFTR:
group 1: -
group 2: shiftl
group 3: shiftr
group 4: shiftl | shiftr
So while a non-default layout group is selected, KG_SHIFTL and/or
KG_SHIFTR are set in shift_state with no Shift key held.
csi_modifier_param() then adds a spurious Shift to every cursor and
CSI key: pressing Up while group 2 is active emits ESC[1;2A (Shift+Up)
instead of ESC[A. KG_ALTGR has the same problem since it is the
standard third-level selector.
Normal keymaps bind the physical Shift/Ctrl/Alt keys to KG_SHIFT,
KG_CTRL and KG_ALT, leaving the left/right and AltGr weights free for
layout and level selection. Count only those canonical weights, so
genuine modifiers are still encoded while layout/level selectors are
not.
Fixes: 4af70f1516 ("vt: add modifier support to cursor keys")
Reported-by: Alexey Gladkov <legion@kernel.org>
Closes: https://lore.kernel.org/kbd/aj2gR0Y7sM6i9s2G@example.org/
Cc: stable <stable@kernel.org>
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
Link: https://patch.msgid.link/20260626024833.3419086-1-nico@fluxnic.net
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The driver currently relies on qcom_geni_serial_pm() through the
uart_ops.pm callback to manage runtime PM references. However, the
callback has a void return type, so failures from
pm_runtime_resume_and_get() cannot be propagated to the caller.
As a result, startup() may continue and access hardware even when the
runtime PM resume operation failed, leading to register accesses while
the device is not powered.
Move runtime PM acquisition to qcom_geni_serial_startup() and release it
to qcom_geni_serial_shutdown(). Since startup() can return an error, PM
resume failures are now detected and propagated before any hardware
initialization is performed. The startup/shutdown pair also provides a
natural place to balance runtime PM references for normal port usage.
During probe, uart_add_one_port() may configure the port before any user
opens the TTY, meaning startup() has not yet been called. To keep the
hardware powered during port registration, wrap uart_add_one_port() with
PM_RUNTIME_ACQUIRE_IF_ENABLED() and PM_RUNTIME_ACQUIRE_ERR(). This
ensures the device is resumed for the duration of registration and that
the runtime PM reference is automatically released afterwards.
By moving runtime PM handling out of uart_ops.pm, resume failures are no
longer silently ignored and all hardware accesses are guaranteed to
occur while the device is powered.
Signed-off-by: Praveen Talari <praveen.talari@oss.qualcomm.com>
Link: https://patch.msgid.link/20260710-remove_uart_change_state-v1-1-8e8468da22a1@oss.qualcomm.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Unlike modern SoCs that just work in both big-endian and little-endian
mode using the readl()/writel() or readb()/writeb() accessors, the
internal registers on ixp4xx behave like native-endian 32-bit registers
in both modes, which requires adjusting the register address
when using 8-bit access.
The existing dts files are written for big-endian kernels and 8-bit
access, which does not work with little-endian kernels.
Add a quirk that makes the 8250 OF driver:
1. Mask off any hardcoded offset.
2. Add the += 3 offset if and only if we are running on big endian.
This should work in all combinations of big-endian and little-endian
kernels with either variant of the DTS file.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
[linusw@kernel.org: Modified to just play with the offset]
Signed-off-by: Linus Walleij <linusw@kernel.org>
Link: https://patch.msgid.link/20260709-ixp4xx-serial-hackfix-v2-1-465fc8e4c54c@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The qcom GENI serial DMA TX completion path advances the transmit fifo by
the number of bytes recorded in port->tx_remaining.
If uart_flush_buffer() runs after the hardware has completed a DMA
transfer but before the DMA completion interrupt has been handled, the
serial core resets the transmit fifo while port->tx_remaining still
describes the old DMA transfer.
A previous fix avoided advancing an empty fifo by checking that the fifo
length is at least tx_remaining. That still does not distinguish the old
DMA payload from new bytes written after the flush. If userspace writes
new data before the stale DMA completion interrupt is handled, the fifo
can again contain at least tx_remaining bytes and the stale completion
can advance and discard those new bytes.
Mark an in-flight DMA transfer stale when the transmit fifo is flushed.
The later completion still unprepares the original DMA mapping using the
saved length, but it no longer advances the transmit fifo.
Fixes: 2aaa43c707 ("tty: serial: qcom-geni-serial: add support for serial engine DMA")
Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
Link: https://patch.msgid.link/20260708131726.768692-1-lgs201920130244@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
During system power-off, systemd closes the console UART and blocks in
tty_wait_until_sent() waiting for pending TX completion before
uart_shutdown() can cancel pending TX operations. With the default
closing_wait of 30s, this causes a watchdog reset when systemd is
responsible for watchdog feeding.
Set closing_wait to ASYNC_CLOSING_WAIT_NONE in startup() for console
ports to bypass tty_wait_until_sent() on close, allowing uart_shutdown()
to cancel TX commands cleanly. This change doesn't impact regular ports
functionality.
Signed-off-by: Aniket Randive <aniket.randive@oss.qualcomm.com>
Link: https://patch.msgid.link/20260706093749.836121-1-aniket.randive@oss.qualcomm.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
During system sleep the hardware resources (clocks, interconnect) are
not gated because the runtime-suspend callback is never invoked from
the system sleep path. This prevents the platform from reaching its
lowest idle state.
The system sleep callbacks qcom_geni_serial_suspend() and
qcom_geni_serial_resume() rely solely on uart_suspend_port() /
uart_resume_port() to manage power. uart_suspend_port() drives the
UART PM state machine to UART_PM_STATE_OFF, which in turn calls
pm_runtime_put_sync() and eventually the runtime-suspend callback.
However, if the runtime-PM usage count is still elevated at the time
of system sleep (e.g. the port is held active by an open file
descriptor), the runtime-suspend callback is never invoked and the
hardware resources (clocks, interconnect) remain enabled across
suspend, preventing the platform from reaching its lowest idle state.
Fix this by calling pm_runtime_force_suspend() at the end of
qcom_geni_serial_suspend() so that the runtime-suspend callback is
always executed regardless of the usage count, and by calling
pm_runtime_force_resume() at the start of qcom_geni_serial_resume()
to restore those resources before uart_resume_port() re-opens the
port.
Signed-off-by: Praveen Talari <praveen.talari@oss.qualcomm.com>
Link: https://patch.msgid.link/20260702-add_force_suspend_resume_to_system_sleep_callbacks-v2-1-b79e254a7015@oss.qualcomm.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
geni_se_rx_dma_prep() calls dma_map_single() which can trigger IOMMU
page table allocations under GFP_KERNEL. This is unsafe when called
from qcom_geni_serial_start_rx_dma(), which runs in atomic context
producing a "sleeping function called from invalid context" splat:
__might_resched+0x15c/0x17c
__alloc_pages_noprof+0xe4/0x4c8
qcom_io_pgtable_alloc_page+0x100/0x250
__arm_lpae_map+0x2d0/0x870
geni_se_rx_dma_prep+0xd8/0x158
qcom_geni_serial_start_rx_dma+0x84/0x16c
qcom_geni_serial_startup+0x70/0x104
Fix this by mapping the RX DMA buffer once during probe, where sleeping
is allowed, and keeping it mapped for the lifetime of the device.
Replace the geni_se_rx_dma_prep() / geni_se_rx_dma_unprep() calls in
the runtime paths with dma_sync_single_for_device() before initiating a
transfer and dma_sync_single_for_cpu() on completion, using the persistent
mapping. The buffer is unmapped in probe's error path and in remove().
Signed-off-by: Praveen Talari <praveen.talari@oss.qualcomm.com>
Link: https://patch.msgid.link/20260701-fix-sleep-in-atomic-context-during-rx-dma-setup-v1-1-95c208380c65@oss.qualcomm.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
USE_OF is already selected by ARM (unless ARCH_FOOTBRIDGE || ARCH_RPC ||
ARCH_SA1100; these all conflict with ARCH_MULTI_V5). So there is no need
for an explicit select and it can be dropped.
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20260705085000.3510576-2-u.kleine-koenig@baylibre.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
ma35d1serial_console_init_port() stores matching UART device nodes in
ma35d1serial_uart_nodes[] with an extra of_node_get() so that console
setup can later read the "reg" property. However, the stored references
are never released after console setup has finished using them.
Drop the stored node reference after ma35d1serial_console_setup() reads
the "reg" property, and clear the array slot to avoid leaving a stale
pointer behind. Also release the iterator reference before breaking out
of for_each_matching_node(), since the normal iterator advance will not
run in that path.
Fixes: 930cbf92db ("tty: serial: Add Nuvoton ma35d1 serial driver support")
Signed-off-by: Yuho Choi <dbgh9129@gmail.com>
Link: https://patch.msgid.link/20260630214043.1887351-1-dbgh9129@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
These changes fix an invalid compatible string combination for GPC DMA
on Tegra264, change the compatible string for the CPU found on Tegra234
and update the unit-address of CPU#1 on Tegra264 so it matches the value
in the "reg" property.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiOrDCAFJzPfAjcif3SOs138+s6EFAmpHyJQACgkQ3SOs138+
s6Fazw/8DDID/ZpOGvkuvGeavCDJl6upY3yaMXYXRWsJY7gh3wMrbT5IIJmT1Z6d
rNW77HN9efW3pedUnaSsKvLGnrauTg4eNNeE+wIqDtLB7zCJffYKmnNAwPrxm7hW
WjPSj1b2gknzwjgsiQ6OfiJ0APVnhKnx7LHnVyhoYGe0PvdVhFH5gNWzsWB/BNaZ
48JivtARTBgF553Mz/7N/CgU2Jrllyx4DafK1EsHzXp7dlQoh6iAW4EBYwOgdcYw
dl/MS3U7QMJire3MNsiQWt4OyhuTVxJrQTJ1KcW/nwotY5/HQ74z4CEDeNkOen1j
9wqmV1mIEx3xaKz/LPESrApEBGeEAkFIlj4uMCLpAv09SdEb08EsoeXyd1X7jPuK
86kEWuETezuBOb/tXr8TzuF6fd0X06u/d2bfBqr9dtrgtF37Tru2CUPxLcE46UsS
sPRrwIUy5XUgkgmw43STtByVLe7jH2XL6JuQMDFGBFOu5VAOEDNlsBgYXcik9nQG
ul6BezASDMG5jODs+4+h+O6/qYGOdtqtIPtyRwb5MTYkRcapBI0Dj9SlWMdldT9T
JqgicKbCLjdD4WCAvyfqAIcRY+UJq8N+xPkC8+G1ksWCoSW3wrGuRLRjgPc6AOco
LmjCmIuUx5nrSWtnhVokpBni2FEM/RbHlLo9PJB5EW9t6LzVlj4=
=tXiU
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmpQ6PkACgkQmmx57+YA
GNkvohAAnHAR/1i3JJOhPJlocRLnci24zt04W/F3+v+qjIxyaNITslbuJz4myHpt
18PjEpPEu1jCdkOVczvLmzXf1b0ZOZ03hbSJ5AHp17IZrpwKy1fK3TUsW97O+Xzz
Duwq7Imbt3lf1yOsu4qCwhzDqVseENEhxmuIBvY0C89PiXd3w9oJGIbp9b8oV5eM
cXVn6X1vgxKxee8SkclLs4AI0uQLir/9gkHn6BbNJ3lJRmWUhcHpUXLBhyfY2n7Q
3Colhzl/Iyyn68en+rdkWXhXHLX267Ht8f4TXVRSV86vXTBKgf/HZHEdzriZus2x
YY9+68SuS/wOjrwLg9PoRbsyg44MDrJS1HE51j+pbRZtZmMoThpzWctNkIDNLOLN
go2yYtxdqz0rYdH0yVwOOzQhmTlYVAlmyA9fUOE1zVsce3GD5XlsWycCKm8Rki+L
tg5oIv9lDDzuwNB5aSE9MwT43BGT5sUri0b7Mj8xdVoP1FOzhc75+TUTxwwPWNaQ
vvvYQdle73Xv4ilKK8VVGxf7d55FULHeyMh/FEzPg3NSgFfH6ElKsfghQg8bkAKm
G7FDr0+PDEudEIDt5mKxlPm4u4h4IfQ6UVGZM5BJDwmcm7y9cPFWFn0E1/QmuPD4
iWTvs2dDUSWlLcSkxI87Yw0cOMeLIWZXZVN9TdHPQu4OrCGwq4g=
=FuhI
-----END PGP SIGNATURE-----
Merge tag 'tegra-for-7.2-arm64-dt-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into arm/fixes
arm64: tegra: Device tree fixes for v7.2
These changes fix an invalid compatible string combination for GPC DMA
on Tegra264, change the compatible string for the CPU found on Tegra234
and update the unit-address of CPU#1 on Tegra264 so it matches the value
in the "reg" property.
* tag 'tegra-for-7.2-arm64-dt-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux:
arm64: tegra: Fix CPU1 node unit-address on Tegra264
arm64: tegra: Fix CPU compatible string to cortex-a78ae on Tegra234
arm64: tegra: Remove fallback compatible for GPCDMA
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
While being less compact, using named initializers allows to more easily
see which members of the structs are assigned which value without having
to lookup the declaration of the struct. And it's also more robust
against changes to the struct definition.
The mentioned robustness is relevant for a planned change to struct
pnp_device_id that replaces .driver_data by an anonymous union.
This patch doesn't modify the compiled array, only their representation
in source form benefits. The former was confirmed with x86 and arm64
builds.
Also simplify the list terminator and use a consistent and more common
indention.
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
Link: https://patch.msgid.link/20260629170409.3412413-2-u.kleine-koenig@baylibre.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
We do unneeded "double free" (emptying an empty list) in one case.
This is not a critical issue at all, the fix just makes code robust
against any possible future changes in the flow.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://patch.msgid.link/20260617092515.2649521-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Replacing strcpy() with strscpy() ensures that overflow of the target
buffer cannot happen.
Signed-off-by: David Laight <david.laight.linux@gmail.com>
Reviewed-by: Daniel Thompson (RISCstar) <danielt@kernel.org>
Link: https://patch.msgid.link/20260608095523.2606-10-david.laight.linux@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add check for pci_get_slot() to prevent a potetial
null pointer dereference in pch_request_dma().
Signed-off-by: Haoxiang Li <haoxiang_li2024@163.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://patch.msgid.link/20260623140539.2272473-1-haoxiang_li2024@163.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The error counter "v->corrupted_errs" was not atomic, thus it could be
subject to race conditions. The call to
dm_audit_log_target("max-corrupted-errors") may be skipped due to the
races.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Assisted-by: Claude:claude-opus-4.6
Fixes: 65ff5b7ddf ("dm verity: add error handling modes for corrupted blocks")
Cc: stable@vger.kernel.org
Log when the BlueField-3 eMMC hardware reset path is invoked.
This makes it easier to diagnose cases where the controller recovery path
depends on issuing an eMMC reset, and helps confirm that the reset sequence
was attempted on affected systems.
Signed-off-by: Satyansh Shukla <satyansh.shukla@oracle.com>
Signed-off-by: Ulf Hansson <ulfh@kernel.org>
The prefix "DM_VERITY_ERR_BLOCK_NR" is 22 chars. Add '=', one digit for
type, ',', up to 20 digits for a u64 block number, and a NUL terminator:
that's 46 bytes. The buffer is 42 bytes. For block numbers >= 16 decimal
digits (devices larger than ~16 EB with 4K blocks), snprintf silently
truncates the uevent environment variable.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Assisted-by: Claude:claude-opus-4.6
Fixes: 65ff5b7ddf ("dm verity: add error handling modes for corrupted blocks")
Cc: stable@vger.kernel.org
Fix a possible NULL pointer dereference dm_verity_loadpin_is_bdev_trusted
if the device has no table.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Assisted-by: Claude:claude-opus-4-6
Fixes: b6c1c5745c ("dm: Add verity helpers for LoadPin")
Cc: stable@vger.kernel.org
verity_parse_opt_args is called twice, first with the only_modifier_opts,
first with only_modifier_opts == true and then with only_modifier_opts ==
false. Thus, the static branch &use_bh_wq_enabled was incremented twice
and the destructor verity_dtr would only decrement it once.
Fix tihs bug by only incrementing it on the first call, on the second
call, when v->use_bh_wq is true, do nothing.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Assisted-by: Claude:claude-opus-4-6
Cc: stable@vger.kernel.org
Fixes: df326e7a06 ("dm verity: allow optional args to alter primary args handling")
The dynamic array stored in the ring buffer already carries its own
length in the array metadata. There is no need to also store it as a
separate scalar field in the entry struct.
Drop __field(unsigned int, len) and the corresponding __entry->len
assignment, and use __get_dynamic_array_len(data) in the TP_printk for
both the len=%u format argument and the __print_hex() size argument.
This saves 4 bytes per event on the ring buffer.
Signed-off-by: Praveen Talari <praveen.talari@oss.qualcomm.com>
Suggested-by: Steven Rostedt <rostedt@goodmis.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://patch.msgid.link/20260615-add-tracepoints-for-qcom-geni-serial-v5-1-2efa4c97e0e2@oss.qualcomm.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
On x86_64 defconfig, booting with driver_async_probe=serial hangs in early
init. The 8250 PNP driver is put onto the async probe pool.
serial8250_register_8250_port() runs in a kworker concurrently with the
ISA registration done from the serial8250_init() initcall resulting in a
deadlock or NULL dereference.
- Deadlock: serial_core_register_port() holds port_mutex across
serial_core_add_one_port()
uart_configure_port()
autoconfig_irq()
probe_irq_on()
async_synchronize_full(),
which waits for the async probe pool to drain.
The async PNP worker reaches the "port already in use" check and
tries to unregister it.
serial8250_register_8250_port()
uart_remove_one_port()
serial_core_unregister_port()
This blocks on port_mutex.
The init thread waits for the worker and the worker waits for the
init thread.
- NULL deref: when the worker instead observes a slot whose port.dev
is set but whose port_dev has not yet been populated, it hits the
null pointer on the call to serial_core_get_ctrl_dev() in
serial_core_unregister_port().
Signed-off-by: Rahul Bukte <rahul.bukte@sony.com>
Link: https://patch.msgid.link/20260610054130.2825182-1-rahul.bukte@sony.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
platform_get_irq is a newer API for this that does not require
irq_dispose_mapping().
Assisted-by: opencode:big-pickle
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://patch.msgid.link/20260607021117.6325-1-rosenp@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This contains two fixes, one for a bad error unwinding path and another
for an #ifdef block that wasn't covering all the combinations correctly.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiOrDCAFJzPfAjcif3SOs138+s6EFAmpHx5gACgkQ3SOs138+
s6GcIg//XYQGOJRyPiYriJjcZvR06OywnLYcXvH3Z3V7jY16CZZKFmv19cJkhEW7
fWynDsic2eE4wXot/aOKmWoQ230AStVJgY4RisUKk8zsd+78BF4vvhsPUIt32SLV
4eRYtzvV2jYs1v8/uvffkj95TmyTcKNcUMBemdklAbWLFtS7BEl8Y/etfPbvWX/B
DtwC/Vz2QyDU7dmU/RJ9/BD5HtpcKRdSBqtdRIT9LOMU68DBSRBgx08n5yvTQEju
COJuNsUqcpZTQkhlTtwSoikpmPtRlpgSixhS8FJ5CVrDokfifChntFIRSI/jgiF1
LUkrj1XPO0bSVcoNa8UNoq/8nox8EY3N1X9WhrhvsjEWHY5fJg49aDlSCiX0UwhL
al7k59YUnKejNCQ7JqZp+O/PABXMsmDDw7eaQwUDl2nYioDUQrQ3ZPlY2RguDD7n
6YsFfkYprf8cLRH+g5TY9m6NSploxS/7Q+/CnPlAolyqc3HozjX6vnbdkzkVsA2g
IG/str1mgeLaEFo5XTl0/bWOnXSgt7XLTj1vWlkHj0qHp5Vmrgz0dB1dEN5SJr0Z
NwiFiqkxJJeoWGxeDzfiLqM/fd8eSzR0LcLSd47qUyVq1eFjGTSXvKGXnxTUYbsr
K/zVwOHFUC6rpPD2gsb7PKgpQZ4QbpOmqpjwWcslrRH4Js3x9A4=
=W7hq
-----END PGP SIGNATURE-----
Merge tag 'tegra-for-7.2-pmc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into arm/fixes
soc/tegra: pmc: Fixes for v7.2
This contains two fixes, one for a bad error unwinding path and another
for an #ifdef block that wasn't covering all the combinations correctly.
* tag 'tegra-for-7.2-pmc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux:
soc/tegra: pmc: fix #ifdef block in header
drm/tegra: Fix a strange error handling path
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
sizeof(tt->version) is 12 bytes, but the code writes 16 bytes into the
output buffer - info->vers->version[0], info->vers->version[1],
info->vers->version[2] and info->vers->next. This can cause buffer
overflow.
Fix this buffer overflow by replacing "sizeof(tt->version)" with
"sizeof(struct dm_target_versions)".
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Assisted-by: Claude:claude-opus-4.6
Cc: stable@vger.kernel.org
When two PnP devices map to the same physical port, the serial8250 driver
removes and re-registers the console structure for the same port.
During re-registration, the console structure still has CON_PRINTBUFFER set
from the initial registration, which causes console_init_seq() to set
console->seq to syslog_seq. This results in re-printing the entire
system log buffer, which may lead to RCU stall on slow serial consoles.
Clear CON_PRINTBUFFER when re-registering a port to prevent duplicate
log printing.
Fixes: 835d844d1a ("8250_pnp: do pnp probe before legacy probe")
Suggested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Fushuai Wang <wangfushuai@baidu.com>
Link: https://patch.msgid.link/20260522101042.21976-1-fushuai.wang@linux.dev
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
If dm_resume fails, the kernel attempts to free table with
dm_table_destroy, but the table was already instantiated with
dm_swap_table. This commit skips the call to dm_table_destroy in this
case.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Assisted-by: Claude:claude-opus-4.6
Fixes: 6bbc923dfc ("dm: add support to directly boot to a mapped device")
Cc: stable@vger.kernel.org
psc_num is derived from port->mapbase bits 11:8, giving a range of
0-15, but the psc_mclk_clk and psc_ipg_clk arrays are sized to
MPC52xx_PSC_MAXNUM (12 when CONFIG_PPC_MPC512x is set). A malformed
device tree with bits 11:8 >= 12 would cause out-of-bounds writes
in mpc512x_psc_alloc_clock() and out-of-bounds reads/writes in
mpc512x_psc_relse_clock() and mpc512x_psc_endis_clock(). The same
unchecked index also appears in mpc512x_psc_handle_irq().
Add ARRAY_SIZE() bounds checks to all four functions before using
psc_num as an array index.
Assisted-by: Opencode:big-pickle
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://patch.msgid.link/20260530061025.11625-1-rosenp@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
If dm_integrity_check_limits fails, the code would exit with
DM_MAPIO_KILL. However, the range would be already locked at this point,
and it wouldn't be unlocked, resulting in a deadlock. Let's move the
limit check up, so that when it exits, no resources are leaked.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Assisted-by: Claude:claude-opus-4.6
Fixes: fb0987682c ("dm-integrity: introduce the Inline mode")
Cc: stable@vger.kernel.org
The mmcblk.perdev_minors module parameter is parsed as a signed int and
is used during mmc_blk_init() to compute the number of supported block
devices.
Passing perdev_minors=0 makes the init path divide by zero when it
computes max_devices. Negative values are invalid as well and would make
max_devices negative before it is later used as an IDA limit.
Reject non-positive perdev_minors values before registering any mmcblk
resources.
Signed-off-by: Xu Rao <raoxu@uniontech.com>
Signed-off-by: Ulf Hansson <ulfh@kernel.org>
hash_offset is already incremented in the loop "for (i = 0; i < to_copy;
i++, ts--)". Do not increment it again.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Assisted-by: Claude:claude-opus-4.6
Fixes: 84597a44a9 ("dm-integrity: dm integrity: add optional discard support")
Cc: stable@vger.kernel.org
If hash size is less than device's tuple size, dm-integrity is supposed
to zero the remaining space. There was a bug in the code that zeroing
didn't work. This commit fixes it.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Assisted-by: Claude:claude-opus-4.6
Fixes: fb0987682c ("dm-integrity: introduce the Inline mode")
Cc: stable@vger.kernel.org
When the "fix_hmac" argument is used, dm-integrity is supposed to check
the superblock with the journal_mac. However, there was a logic bug in
the code - the code only checked the superblock mac if the bit
SB_FLAG_FIXED_HMAC was set in the superblock. So, the attacker could
clear this bit and bypass the checking trivially.
This commit changes dm-integrity so that when the user specified the
"fix_hmac" flag and the superblock doesn't have the bit
SB_FLAG_FIXED_HMAC set, the activation is aborted with an error.
Unfortunatelly, there's a bug in the integritysetup tool that when using
the 'open' command it passes the "fix_hmac" argument to the kernel even
if the user specified --integrity-legacy-hmac. The bug will be fixed in
the upcoming 2.8.7 release.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Reported-by: Shukai Ni <shukai.ni@kuleuven.be>
bui duc phuc <phucduc.bui@gmail.com> says:
It replaces dev_err() followed by return with dev_err_probe() where
appropriate in probe paths, allowing deferred probe to be handled
correctly while simplifying the code.
It also removes redundant dev_err() calls after helper functions that
already report failures, avoiding duplicate error messages.
Link: https://patch.msgid.link/20260710102138.29347-1-phucduc.bui@gmail.com
Use dev_err_probe() for probe error handling where appropriate to
simplify the code and properly handle deferred probe.
Also remove redundant error messages when the called helper already
reports failures, returning the error directly to avoid duplicate
logging.
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
Reviewed-by: Michal Simek <michal.simek@amd.com>
Link: https://patch.msgid.link/20260710102138.29347-4-phucduc.bui@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
devm_request_irq() can return various error codes, such as -EINVAL,
-ENOTCONN, -ENOMEM, -ENOSYS, and -EBUSY. However, the driver
overwrites all of them with -ENODEV, which hides the actual cause of
the failure.
Also, devm_request_irq() already reports failures internally, so the
additional dev_err() call is redundant.
Return the original error code and remove the duplicate error message.
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
Reviewed-by: Michal Simek <michal.simek@amd.com>
Link: https://patch.msgid.link/20260710102138.29347-3-phucduc.bui@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Use dev_err_probe() for probe error handling where appropriate to
simplify the code and properly handle deferred probe.
Also remove redundant error messages when the called helper already
reports failures, returning the error directly to avoid duplicate
logging.
Reviewed-by: Michal Simek <michal.simek@amd.com>
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
Link: https://patch.msgid.link/20260710102138.29347-2-phucduc.bui@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
We can rearrange a bit the function to reduce the indentation levels.
No functional change added to this patch.
Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Split out the wait function, and introduce some new toys: guard and
lockdep.
This fixes the following cocci warnings:
drivers/media/dvb-core/dvb_frontend.c:2897:1-7: preceding lock on line 2776
drivers/media/dvb-core/dvb_frontend.c:2897:1-7: preceding lock on line 2786
drivers/media/dvb-core/dvb_frontend.c:2897:1-7: preceding lock on line 2809
Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Move the actual opening to its own function.
Not intended code change. This is a preparation for the next patch.
Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Coccinelle triggers a false positive where it thinks that the priv
variable in helene_attach_s and helene_attach is the same variable as
helene_probe. This is due to a bad heuristic in cocci.
We have reported it to cocci, but until/if this is fixed, renaming a
local variable is a good compromise to fix this warning:
./dvb-frontends/helene.c:1049:2-7: WARNING: invalid free of devm_ allocated data
./dvb-frontends/helene.c:1013:2-7: WARNING: invalid free of devm_ allocated data
Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
We are using the refcnt variable for refcounting. Use the refcount_t
type instead, as it has support for saturation and underflow.
This also makes cocci happier, as it will fix the following warning:
./platform/amd/isp4/isp4_subdev.c:394:6-25: WARNING: atomic_dec_and_test variation before object free at line 395.
Fixes: 4c5feef6a6 ("media: platform: amd: Add isp4 fw and hw interface")
Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
Reviewed-by: Pratap Nirujogi <pratap.nirujogi@amd.com>
Reviewed-by: Bin Du <bin.du@amd.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
pixel_rate is set to VIMC_PIXEL_RATE_FIXED, which the code expects to
fit in 32 bits. Make that constraint into a WARN_ON, so if we ever break
that constraint a kernel warning will be triggered.
It also fixes the following cocci warning:
./test-drivers/vimc/vimc-sensor.c:107:1-7: WARNING: do_div() does a 64-by-32 division, please consider using div64_u64 instead.
Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
The function does not return any value, make it into a void function.
Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
The max() macro is simpler to read than the current construction, it
also makes cocci happier, which currently throws these warnings:
./platform/qcom/iris/iris_vpu_buffer.c:703:13-15: WARNING opportunity for max()
./platform/qcom/iris/iris_vpu_buffer.c:583:23-25: WARNING opportunity for max()
Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
