| Age | Commit message (Collapse) | Author |
|
ovpn_peer_endpoints_update() builds the new remote endpoint in an
on-stack struct sockaddr_storage that is left uninitialized. For IPv4
only sin_family/sin_addr/sin_port are written, leaving the 8-byte
sin_zero padding as stack garbage (for IPv6, sin6_flowinfo is left
uninitialized likewise).
ovpn_peer_reset_sockaddr() -> ovpn_bind_from_sockaddr() then memcpy()s
sizeof(struct sockaddr_in)/sizeof(struct sockaddr_in6) bytes - padding
included - into bind->remote. That buffer is later hashed with jhash()
over the same length to place the peer in the by_transp_addr table, so
the garbage padding lands the floated peer in an essentially random
bucket. Lockless lookups in ovpn_peer_get_by_transp_addr() build their
key from a zero-initialized sockaddr_storage, compute a different bucket
and fail to find the peer.
This is also a plain use of uninitialized stack memory in jhash().
Build the floated endpoint with a designated initializer so the
padding (sin_zero for IPv4, sin6_flowinfo for IPv6) is zeroed as part
of the assignment. This keeps the padding out of the by_transp_addr
hash key without memset-ing the whole sockaddr_storage on every
received packet.
Fixes: f0281c1d3732 ("ovpn: add support for updating local or remote UDP endpoint")
Signed-off-by: Antonio Quartulli <antonio@openvpn.net>
|
|
Some subsystems, like BPF SOCKMAP, set sk_user_data without
actually setting the encap_type.
For this reason, we must make sure that the type is the
one ovpn expects before dereferencing sk_user_data.
Failing to do so may lead to out-of-bounds reads.
Fixes: f6226ae7a0cd ("ovpn: introduce the ovpn_socket object")
Signed-off-by: Antonio Quartulli <antonio@openvpn.net>
|
|
When userspace updates a peer's remote endpoint via OVPN_CMD_PEER_SET,
ovpn_nl_peer_modify() installs a new ovpn_bind through
ovpn_peer_reset_sockaddr(), but ovpn_nl_peer_set_doit() only calls
ovpn_peer_hash_vpn_ip() to refresh the VPN-IP hashtables. The peer is
left in the bucket of peers->by_transp_addr corresponding to its old
remote address.
As a consequence, datagrams arriving at the UDP RX path from the newly
configured remote hash to a different slot and the lockless lookup in
ovpn_peer_get_by_transp_addr() (called from ovpn_udp_encap_recv()) does
not find the peer, until either a float event or a peer re-add fixes
the bucket.
Introduce ovpn_peer_hash_transp_addr() (modeled after
ovpn_peer_hash_vpn_ip()) and invoke it from ovpn_nl_peer_set_doit()
whenever the request carried a new remote address. The helper bails
out in P2P mode and on peers without a bind (TCP), and relies on
hlist_nulls_del_init_rcu()'s pprev==NULL short-circuit to handle the
case of an entry not currently linked in the table.
Fixes: 1d36a36f6d53 ("ovpn: implement peer add/get/dump/delete via netlink")
Signed-off-by: Antonio Quartulli <antonio@openvpn.net>
|
|
ovpn_nl_peer_set_doit() resolves the target peer via
ovpn_peer_get_by_id() before taking ovpn->lock. In the window between
the lookup (which only takes a refcount) and the subsequent
spin_lock_bh(&ovpn->lock), a concurrent OVPN_CMD_PEER_DEL, keepalive
expiry, or socket teardown can take ovpn->lock first, run
ovpn_peer_remove() to unhash the peer from all four tables (by_id,
by_vpn_addr4/6, by_transp_addr) and release the lock. set_doit then
acquires ovpn->lock and calls ovpn_peer_hash_vpn_ip(), which
re-inserts the now-removed peer back into the rehashing tables.
The same race affects the float path: ovpn_peer_endpoints_update()
holds only a refcount and acquires ovpn->lock very late (after async
AEAD decrypt and a netlink notification), then rehashes the peer
in the by_transp_addr table.
The resurrected peer becomes reachable again from the RX lookup
(ovpn_peer_get_by_transp_addr) and the TX VPN-IP lookup, even though
userspace believes it is gone. Once the data-path refcount drops the
peer is freed via call_rcu while the hash entries embedded in it
remain linked, opening a UAF window.
Bail out of the rehash when hash_entry_id is unhashed, mirroring
the sentinel already used by ovpn_peer_remove() to detect the
already-removed state. The check is safe under ovpn->lock, which
serializes every mutation of hash_entry_id, and is a no-op for the
add path because ovpn_peer_add_mp() inserts hash_entry_id before
calling ovpn_peer_hash_vpn_ip().
Fixes: 1d36a36f6d53 ("ovpn: implement peer add/get/dump/delete via netlink")
Signed-off-by: Antonio Quartulli <antonio@openvpn.net>
|
|
Large keepalive values can overflow the delayed-work delay on 32-bit
systems, causing the keepalive worker to be repeatedly scheduled.
A correct configuration should not require such large keepalive values,
and an upper limit of one day is already generous and unnecessary in
practice. Limit both the keepalive interval and timeout to 86400 seconds.
Signed-off-by: Marco Baffo <marco@mandelbit.com>
Signed-off-by: Antonio Quartulli <antonio@openvpn.net>
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/mediatek/linux into soc/drivers
MediaTek SoC driver updates
This adds a fix for a missing error check in mtk-socinfo, and
also a missing MODULE_DEVICE_TABLE() in the mtk-dvfsrc driver.
Besides from that, this also reworks how the MMSYS tables are
specified with the macro, separating the component's hardware
instance from the actual type, resolving a prerequirement for
the restructuring of mediatek-drm.
* tag 'mtk-soc-for-v7.3' of https://git.kernel.org/pub/scm/linux/kernel/git/mediatek/linux:
soc: mediatek: add missing MODULE_DEVICE_TABLE()
soc: mediatek: mtk-mmsys: Use MMSYS_ROUTE() in default routing table
soc: mediatek: mtk-mmsys: Rework routes to specify component ID
soc: mediatek: mtk-socinfo Add error handling in devm_kasprintf()
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
Add exclusive open mode capability to AT and QCDM ports to improve
compatibility with user-space tools using the Qualcomm diagnostic
device (e.g. libqcdm).
Signed-off-by: Daniele Palmas <dnlplm@gmail.com>
Reviewed-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
Link: https://patch.msgid.link/20260724142909.3270824-3-dnlplm@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
Upstream libqcdm requires IOCTLs support to work, so add the current
AT minimalistic support also to the QCDM port.
Reviewed-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
Signed-off-by: Daniele Palmas <dnlplm@gmail.com>
Link: https://patch.msgid.link/20260724142909.3270824-2-dnlplm@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
Add support for the GPIO controller found on Realtek DHC RTD1625 SoCs.
Unlike the existing Realtek GPIO driver (drivers/gpio/gpio-rtd.c),
which manages pins via shared bank registers, the RTD1625 introduces
a per-pin register architecture. Each GPIO line now has its own
dedicated 32-bit control register to manage configuration independently,
including direction, output value, input value, interrupt enable, and
debounce. Therefore, this distinct hardware design requires a separate
driver.
The RTD1625 GPIO controller has a hardware quirk where both 'assert'
and 'de-assert' interrupts are fired simultaneously on any edge toggle.
The driver works around this quirk to correctly handle edge interrupts.
Interrupt support is optional for this device, matching the dt-bindings.
If the interrupts property is not provided, the driver simply skips IRQ
initialization and operates purely as a basic GPIO controller.
Reviewed-by: Linus Walleij <linusw@kernel.org>
Signed-off-by: Tzuyi Chang <tychang@realtek.com>
Co-developed-by: Yu-Chun Lin <eleanor.lin@realtek.com>
Signed-off-by: Yu-Chun Lin <eleanor.lin@realtek.com>
Reviewed-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Link: https://patch.msgid.link/20260726125209.140307-10-eleanor.lin@realtek.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
|
|
Add gpio_regmap_enable_irq() and gpio_regmap_disable_irq(). Since struct
gpio_regmap is opaque, drivers cannot access the embedded gpio_chip directly.
Reviewed-by: Michael Walle <mwalle@kernel.org>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Suggested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Yu-Chun Lin <eleanor.lin@realtek.com>
Link: https://patch.msgid.link/20260726125209.140307-9-eleanor.lin@realtek.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
|
|
Add a new set_config callback to allow drivers to implement
hardware-specific configuration such as debounce settings, or other
platform-specific GPIO properties.
Reviewed-by: Michael Walle <mwalle@kernel.org>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Signed-off-by: Yu-Chun Lin <eleanor.lin@realtek.com>
Link: https://patch.msgid.link/20260726125209.140307-8-eleanor.lin@realtek.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
|
|
Introduce a new optional 'value_xlate' callback. This routine allows drivers
to translate or modify the register value and mask immediately before a write
operation. It is particularly useful for hardware that requires additional
control bits, such as a write-enable bit, to be appended to the data
dynamically.
Reviewed-by: Michael Walle <mwalle@kernel.org>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Suggested-by: Michael Walle <mwalle@kernel.org>
Signed-off-by: Yu-Chun Lin <eleanor.lin@realtek.com>
Link: https://patch.msgid.link/20260726125209.140307-7-eleanor.lin@realtek.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
|
|
Extend the reg_mask_xlate callback with an operation type parameter
(enum gpio_regmap_operation) to allow drivers to return different
register/mask combinations depending on the specific GPIO operation.
Consequently, update all existing drivers utilizing the gpio-regmap
framework (across drivers/gpio, drivers/iio, and drivers/pinctrl)
to accommodate the new reg_mask_xlate function signature.
Acked-by: William Breathitt Gray <wbg@kernel.org>
Acked-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com> #for-iio
Suggested-by: Linus Walleij <linusw@kernel.org>
Signed-off-by: Yu-Chun Lin <eleanor.lin@realtek.com>
Link: https://patch.msgid.link/20260726125209.140307-6-eleanor.lin@realtek.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
|
|
When GPIO regmap creates an IRQ chip on behalf of the user, it also
takes an ownership of the respective callbacks and driver data.
With that being done, apply default resource callbacks that keep
tracking the IRQ requests and releases.
Reviewed-by: Michael Walle <mwalle@kernel.org>
Reviewed-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Yu-Chun Lin <eleanor.lin@realtek.com>
Link: https://patch.msgid.link/20260726125209.140307-4-eleanor.lin@realtek.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
|
|
When GPIO regmap based driver supplies its own IRQ domain, it might
still want to keep track of the IRQ requests and releases, in particular
to prevent a GPIO, which is used and locked as IRQ, to be requested
via standard ways. Provide default callbacks for such cases and keep
struct gpio_chip private to GPIO regmap implementation.
Reviewed-by: Michael Walle <mwalle@kernel.org>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Yu-Chun Lin <eleanor.lin@realtek.com>
Link: https://patch.msgid.link/20260726125209.140307-3-eleanor.lin@realtek.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
|
|
This reverts commit a57e27c43b0315ee86c6896510d69be5257e093e.
The driver will be rewritten to use the gpio-regmap infrastructure
once Andy Shevchenko's patches for gpio-regmap are applied.
Acked-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Acked-by: Linus Walleij <linusw@kernel.org>
Signed-off-by: Yu-Chun Lin <eleanor.lin@realtek.com>
Link: https://patch.msgid.link/20260726125209.140307-2-eleanor.lin@realtek.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/frank.li/linux into soc/arm
i.MX SoC Changes for v7.3
- Fix OF/device_node reference count leaks in imx_src_init(),
imx7_src_init(), and the AVIC interrupt controller driver
- Drop obsolete/unused declarations from `arch/arm/mach-imx/common.h`
- firmware: imx: scu: Refactor mailbox channel management to use a
per-instance handle instead of a global one
- firmware: imx: sm-misc: Add NULL check for `kmalloc` return value in
syslog_show
- soc: imx9: Add error handling for `devm_kasprintf` return value
* tag 'imx-soc-7.3' of https://git.kernel.org/pub/scm/linux/kernel/git/frank.li/linux:
firmware: imx: scu: manage mailbox channels and global handle
soc: imx9: devm_kasprintf error handling
ARM: imx: Drop obsolete stuff from common.h
firmware: imx: sm-misc: Add NULL check for kmalloc in syslog_show
ARM: imx: fix device_node refcount leaks in imx7_src_init()
ARM: imx: fix device_node refcount leak in imx_src_init()
ARM: imx: avic: Fix OF node reference leaks
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
max_nr_stripes is updated under cache_size_mutex in the stripe cache
grow/shrink paths, while is_inactive_blocked() and
raid5_end_read_request() read it without that lock.
Use READ_ONCE() for those reads in lockless path to match the WRITE_ONCE()
updates and avoid KCSAN data race reports.
A similar issue was previously fixed in commit-id:
dfd2bf436709b2bccb78c2dda550dde93700efa7.
Fixes: 0009fad03337 ("raid5 improve too many read errors msg by adding limits")
Fixes: 3514da58be9c ("md/raid5: Make is_inactive_blocked() helper")
KCSAN report:
=================
BUG: KCSAN: data-race in grow_one_stripe / is_inactive_blocked
write (marked) to 0xffff8f01f0b5a268 of 4 bytes by task 12616 on cpu 9:
grow_one_stripe+0x2d8/0x320
raid5d+0xb57/0xba0
md_thread+0x15a/0x2d0
[..........]
read to 0xffff8f01f0b5a268 of 4 bytes by task 12670 on cpu 11:
is_inactive_blocked+0x97/0xc0
raid5_get_active_stripe+0x2fd/0xa70
raid5_make_request+0x4aa/0x2940
[..........]
value changed: 0x000003b9 -> 0x000003ba
Signed-off-by: Chen Cheng <chencheng@fnnas.com>
Reviewed-by: Yu Kuai <yukuai@fygo.io>
Link: https://patch.msgid.link/20260624024042.2561803-1-chencheng@fnnas.com
Signed-off-by: Yu Kuai <yukuai@fygo.io>
|
|
The patch just suppress KCSAN noise. No functional change.
KCSAN reports a race, point to update_read_sectors() update next_seq_sect vs.
read next_seq_sect.
Protect next_seq_sect and seq_start with READ_ONCE/WRITE_ONCE, otherwise,
read balance see stale sequential-read hints.
KCSAN report:
==============
BUG: KCSAN: data-race in raid1_read_request / raid1_read_request
write to 0xffff8e3a2d6736d0 of 8 bytes by task 593784 on cpu 10:
raid1_read_request+0xe5a/0x19f0
raid1_make_request+0xdf/0x1990
md_handle_request+0x4a2/0xa40
[...]
read to 0xffff8e3a2d6736d0 of 8 bytes by task 593776 on cpu 11:
raid1_read_request+0xe3f/0x19f0
raid1_make_request+0xdf/0x1990
md_handle_request+0x4a2/0xa40
[...]
value changed: 0x0000000000356368 -> 0x0000000000356370
Signed-off-by: Chen Cheng <chencheng@fnnas.com>
Reviewed-by: Yu Kuai <yukuai@fygo.io>
Link: https://patch.msgid.link/20260623075940.2476255-1-chencheng@fnnas.com
Signed-off-by: Yu Kuai <yukuai@fygo.io>
|
|
Enable RMII interface in the lan743x driver for PHY and MAC
configuration.
- Select RMII interface in lan743x_phy_interface_select().
- Update phylink supported_interfaces and MAC capabilities.
- Enable RMII via RMII_CTL in lan743x_hardware_init().
- Define RMII_CTL register and enable bit in lan743x_main.h.
EEE is not supported with RMII on PCI11x1x: the hardware does not
implement LPI signaling over RMII. Clear RMII from lpi_interfaces to
prevent phylink from enabling EEE on this interface.
Signed-off-by: Thangaraj Samynathan <thangaraj.s@microchip.com>
Link: https://patch.msgid.link/20260723050827.694832-3-Thangaraj.S@microchip.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
Extend pci11x1x_strap_get_status() to read the RMII strap bits from
the STRAP_READ register. The is_rmii_en flag is initialized to
false and updated based on the hardware strap only if SGMII is not
already enabled. This ensures correct interface identification during
adapter initialization.
Update the netif_dbg() to report the selected interface as SGMII,
RMII, or RGMII.
Signed-off-by: Thangaraj Samynathan <thangaraj.s@microchip.com>
Link: https://patch.msgid.link/20260723050827.694832-2-Thangaraj.S@microchip.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
The loop in ppl_do_flush() continues iterating after calling
ppl_io_unit_finished(), touching io->pending_flushes and leading to a
use-after-free.
Add a break statement to stop the loop once io is freed.
Fixes: 1532d9e87e8b ("raid5-ppl: PPL support for disks with write-back cache enabled")
Reported-by: Dan Carpenter <error27@gmail.com>
Closes: https://lore.kernel.org/all/ajJF2wKYWRk4GGCK@stanley.mountain/
Signed-off-by: Sajal Gupta <sajal2005gupta@gmail.com>
Reviewed-by: Yu Kuai <yukuai@fygo.io>
Link: https://patch.msgid.link/20260622142146.56637-1-sajal2005gupta@gmail.com
Signed-off-by: Yu Kuai <yukuai@fygo.io>
|
|
The driver has an OF match table wired to .of_match_table, but does
not export the table with MODULE_DEVICE_TABLE().
Add the missing MODULE_DEVICE_TABLE(of, ...) entry so module alias
information is generated for OF based module autoloading.
This is a source-level fix. It does not claim dynamic hardware
reproduction; the evidence is the driver-owned match table, its use by
the platform driver, and the missing module alias publication.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
|
|
All of the mtk_mmsys_routes tables for all SoCs were converted to
use the MMSYS_ROUTE() macro but the default one used for MT2701,
MT2712 and SoCs from that generation was not: convert this one as
well.
This brings no functional change.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
|
|
In preparation for a refactoring of multimedia related MediaTek
drivers, including mmsys, mutex and mediatek-drm, rework all of
the MMSYS routes to specify a hardware component instance number
(or "SubID") alongside the hardware component type.
This also is one step of preparation towards the removal of the
catch-all mtk_ddp_comp_id enumeration and towards the migration
from a predefined-coupling static hardware component IDSubID
mapping (carrying around a very long enumeration and also some
multiple big arrays in mediatek-drm) to a more flexible map of
Component ID (Type) decoupled from Component SubID (HW Instance)
as then, anyway, techniques to handle components are always the
same on a type basis.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
|
|
Both branches of the check return the same value, so the check has
no effect. Remove it and return the value directly.
This is the result of running the Coccinelle script from
scripts/coccinelle/misc/cond_return_no_effect.cocci.
Signed-off-by: Sang-Heon Jeon <ekffu200098@gmail.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
Remove the local variables, add default cases, and return the strings
directly.
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
Remove the local ret variable and return the result directly.
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
Use memcpy_and_pad() instead of memcpy() followed by memset() to
simplify ahash_hmac_setkey().
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
mv_cesa_put_sram() is called explicitly from both the probe error path
and mv_cesa_remove(). The non-pool ioremap is already devm-managed, but
dma_map_resource() and gen_pool_dma_alloc() have no devm helpers, so the
mapping is released by hand. This is error-prone: the error path iterates
over every engine and can dma_unmap_resource() an uninitialized/zero
address for engines that were never set up.
Convert the teardown into a devm_add_action_or_reset() callback registered
only after a mapping is successfully established. The callback fires
automatically on probe failure (devres rollback) and on device detach,
after mv_cesa_remove() has already stopped the engine and freed the IRQ,
so the unmap still happens in a safe order. This deletes the explicit
mv_cesa_put_sram() calls and the uninitialized-engine bug at once.
Add a struct mv_cesa_dev back-pointer to struct mv_cesa_engine so the
callback can reach cesa->dev and cesa->sram_size from the engine alone.
Assisted-by: opencode:hy3-free
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
Using sg_dma_len() is only valid after mapping a scatterlist with
dma_map_sg(). However, starfive_aes_aead_do_one_req() uses it before
mapping the scatterlist.
Use the original scatterlist length because the DMA length has not been
populated yet when CONFIG_NEED_SG_DMA_LENGTH=y.
Fixes: 7467147ef9bf ("crypto: starfive - Use dma for aes requests")
Cc: stable@vger.kernel.org
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
If ops->register_algs() fails, the error path repeatedly calls the same
ops->unregister_algs() from the failed registration. Use the loop index
to unregister the previously registered algorithms instead.
Fixes: e80cf84b6087 ("crypto: qce - unregister previously registered algos in error path")
Cc: stable@vger.kernel.org
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
Perform rctx->cryptlen calculation in tegra_gcm_do_one_req() the same way
it is done in tegra_ccm_crypt_init(). The current formulae may lead to a
crash if a caller does not call tegra_gcm_setauthsize() and so ctx->authsize
remains zero. Then a decrypt operation with incorrect rctx->cryptlen will
lead to a write beyound rctx->dst_sg buffer.
As a follow-up cleanup delete struct tegra_aead_ctx->authsize field since
it appears to be completely unused. Also simplify tegra_ccm_setauthsize()
and tegra_gcm_setauthsize() functions respectively.
Fixes: 0880bb3b00c8 ("crypto: tegra - Add Tegra Security Engine driver")
Signed-off-by: Vladislav Dronov <vdronov@redhat.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
kcsan detect race :
- raid5d() closes the current bitmap batch by updating
conf->seq_flush under conf->device_lock.
- __add_stripe_bio() read conf->seq_flush without that
lock when assigning sh->bm_seq.
so, protect seq_flush/seq_write consistency for multiple CPUs by
READ_ONCE()/WRITE_ONCE() under the path without held device_lock.
re-explain the stripe batch sequence number update flow:
1. sh->bm_seq declare which batch number the stripe belongs to
when perform bitmap-related write.
==> bm_seq = seq_flush+1
2. stripe be handled,
* if sh->bm_seq - conf->seq_write > 0, means the
batch stripes **newer than** the last written
batch, it cannot proceed yet, queued on bitmap_list.
* otherwise , has already proceed.
3. raid5d() `++seq_flush` to closes the current batch, means
* no more stripes join that old batch
* just-closed batch ready to write-out to disk
4. raid5d() calls bitmap hooks unplug() or writeout, then,
`++seq_write` to the same as bm_seq.
- seq_flush - for producer, to close batches.
- seq_write - for consumer, the checkpoint number.
the report:
====================================
BUG: KCSAN: data-race in __add_stripe_bio / raid5d
write to 0xffff88ba5625d470 of 4 bytes by task 82401 on cpu 0:
raid5d+0x1d9/0xba0
[.....]
read to 0xffff88ba5625d470 of 4 bytes by task 82421 on cpu 8:
__add_stripe_bio+0x332/0x400
raid5_make_request+0x6ac/0x2930
md_handle_request+0x4a2/0xa40
md_submit_bio+0x109/0x1a0
__submit_bio+0x2ec/0x390
[.....]
Fixes: 7c13edc87510 ("md: incorporate new plugging into raid5.")
v1 -> v2:
- remove WRITE_ONCE(conf->seq_write) in held device_lock path.
- remove READ_ONCE(conf->seq_flush) in held device_lock path.
Signed-off-by: Chen Cheng <chencheng@fnnas.com>
Reviewed-by: Yu Kuai <yukuai@fygo.io>
Link: https://patch.msgid.link/20260622124649.1780233-1-chencheng@fnnas.com
Signed-off-by: Yu Kuai <yukuai@fygo.io>
|
|
The skb passed to the rtw_hci_tx_write() is expected to be freed when
the function fails, but the error path in rtw_txq_push_skb() does not
free the skb before returning. This can lead to a memory leak in
rtw_txq_push() where a dequeued skb is passed to rtw_txq_push_skb().
Fixes: aaab5d0e6737 ("rtw88: kick off TX packets once for higher efficiency")
Cc: stable@vger.kernel.org
Signed-off-by: Abdun Nihaal <nihaal@cse.iitm.ac.in>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260727064223.61836-1-nihaal@cse.iitm.ac.in
|
|
Both branches of the check return the same value, so the check has
no effect. Remove it and return the value directly.
This is the result of running the Coccinelle script from
scripts/coccinelle/misc/cond_return_no_effect.cocci.
Signed-off-by: Sang-Heon Jeon <ekffu200098@gmail.com>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260726134034.1385834-3-ekffu200098@gmail.com
|
|
_rtl8821ae_llt_write()
Both branches of the check return the same value, so the check has
no effect. Remove it and return the value directly.
This is the result of running the Coccinelle script from
scripts/coccinelle/misc/cond_return_no_effect.cocci.
Signed-off-by: Sang-Heon Jeon <ekffu200098@gmail.com>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260726134034.1385834-2-ekffu200098@gmail.com
|
|
The MHI core needs to make sure that all the current DMA transactions are
completed before removing the channels. So implement the
mhi_cntrl->flush_async() callback by first making sure all the in-flight
DMA operations are completed and then flushing the DMA workqueue.
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
|
|
mhi_ep_abort_transfer()
mhi_ep_abort_transfer() notifies the client drivers about the channel
disconnect using -ENOTCONN and only then flushes the ring workqueue to
drain the in-flight transfers. But the async DMA transfers issued by the
ring workers can still complete after the notification. And the completion
handlers trigger the client xfer_cb() as long as it is set.
So a transfer completing during the flush can deliver a success callback to
the client even after it has been notified about the disconnect. This can
lead to UAF (Use-After-Free) issues as the client can free its per-transfer
resources in response to the -ENOTCONN notification and the trailing
success callback would then reference the freed resources.
So to fix this issue, disable all the channels first to prevent new
transfers and then drain both the ring workqueue and the in-flight async
transfers before notifying the disconnect. The completion and queue paths
bail out once the channel state is not MHI_CH_STATE_RUNNING, so disabling
the channels upfront makes sure that no new transfer sneaks in during the
drain and all the pending completions are delivered while xfer_cb() is
still valid.
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
|
|
read/write
MHI EP stack makes use of the MHI controller drivers like MHI EPF to do
read/write to the host memory. And that driver is free to use mechanisms
like DMA to offload the read/write operations.
So if DMA is used for offload, then there is no guarantee that those DMA
operations would be completed by the time mhi_ep_remove() gets called. This
can lead to UAF (Use-After-Free) issues as the DMA callback can trigger
xfer_cb() even after mhi_ep_remove() has returned.
So to fix this issue, introduce the mhi_cntrl->flush_async() callback and
call it in mhi_ep_remove() to drain all the in-flight async transfers
before disconnecting the channels.
The completion handlers keep triggering xfer_cb() as long as it is set. So
flushing the transfers after notifying the client about the disconnect
(-ENOTCONN) would still let a success callback slip through afterwards and
lead to the same UAF. So disable the channels first to prevent new
transfers, then flush the in-flight transfers so that their completions are
delivered while xfer_cb() is still valid and only then notify the
disconnect and clear xfer_cb().
Fixes: 2547beb00ddb ("bus: mhi: ep: Add support for async DMA read operation")
Fixes: ee08acb58fe4 ("bus: mhi: ep: Add support for async DMA write operation")
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Cc: stable+noautosel@kernel.org # Needs dmaengine driver fix as well
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
|
|
mhi_register_controller() adds the controller device before creating the
optional trigger_edl sysfs file. If sysfs_create_file() fails, the error
path only drops the device reference and leaves the device registered.
Hence, call device_del() in the error path before put_device().
Fixes: 17553ba8e19d ("bus: mhi: host: Add sysfs entry to force device to enter EDL")
Signed-off-by: Yuho Choi <dbgh9129@gmail.com>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
|
|
Add SAHARA channel to support capturing crash dump (ramdump) using the
in-kernel sahara client driver.
Signed-off-by: Slark Xiao <slark_xiao@163.com>
[mani: commit log]
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
|
|
Commit 0494cf9793b7 ("bus: mhi: host: pci_generic: Disable runtime PM for
QDU100") added the 'no_m3' flag to indicate that the QDU100 device doesn't
support M3 state and used this flag to skip runtime PM. But it didn't
prevent the MHI bus from transitioning the device to M3 during system
suspend.
So set 'mhi_cntrl->no_m3' flag based on the local 'info->no_m3' flag to
indicate MHI bus that this device doesn't support M3 state so that it can
skip the transition.
Cc: stable+noautosel@kernel.org # depends on the 'mhi_cntrl->no_m3' flag addition
Fixes: 0494cf9793b7 ("bus: mhi: host: pci_generic: Disable runtime PM for QDU100")
Reported-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
|
|
MHI bus transitions the device into M3 state during suspend and back to M0
state during resume. But due to hardware issues, some devices do not
support M3 state. To support these devices properly, MHI bus needs to skip
transitioning the device to M3 during suspend and back to M0 during resume.
For this purpose, introduce the 'mhi_cntrl->no_m3' flag and allow it to be
set by the MHI controller drivers. Once set, this flag lets the MHI bus
skip transitioning the device to M3/M0 during suspend/resume.
But, simply skipping suspend/resume for such devices is not sufficient, as
it leaves the MHI host in M0 state with device access enabled. Client
drivers that do not implement PM callbacks (for instance, the non-freezable
rx_refill worker in mhi_net driver) could then keep ringing channel
doorbells and issue MMIO to the device even after the controller driver has
disabled it and moved it to D3 during its own suspend, resulting in access
to a powered down device.
So instead of skipping the entire suspend/resume operation, run the full
host suspend/resume sequence but without the device-side M state handshake.
During suspend, only transition the host to M3 without sending the MHICTRL
M3 command or waiting for the device M3 event. During resume, bring the
host back to M0 through mhi_pm_m0_transition() without sending the MHICTRL
M0 command.
With the host in M3, all device access is gated by MHI_DB_ACCESS_VALID()
and MHI_REG_ACCESS_VALID(), so any transfer queued by the clients during
suspend is deferred until resume, where mhi_pm_m0_transition() rings the
pending doorbells.
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
|
|
mhi_soc_reset() tries to reset the device by writing to the
MHI_SOC_RESET_REQ_OFFSET register. But it doesn't do a read-back to ensure
that the write gets flushed to the device before returning to the caller.
This may lead to the delay (if implemented) on the caller to be
insufficient, if the posted write doesn't reach the device before the
delay.
So add a read-back after writing to the MHI_SOC_RESET_REQ_OFFSET register.
Fixes: b5a8d233a588 ("bus: mhi: core: Add device hardware reset support")
Reported-by: Alex Williamson <alex@shazbot.org>
Closes: https://lore.kernel.org/linux-pci/20260622160822.09350246@shazbot.org
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Reviewed-by: Jeff Hugo <jeff.hugo@oss.qualcomm.com>
Link: https://patch.msgid.link/20260623145134.43976-1-manivannan.sadhasivam@oss.qualcomm.com
|
|
Both Woody and Marek reported following crash:
BUG: unable to handle page fault for address: fffffffffffffff8
Call Trace:
<TASK>
device_release+0x43/0x90
kobject_cleanup+0x3c/0x180
icm_probe+0x19c/0x550 [thunderbolt]
nhi_probe+0x1a4/0x370 [thunderbolt]
local_pci_probe+0x41/0x90
pci_call_probe+0x5b/0x1a0
...
This only triggers on the error path when icm_probe() fails and the
domain structure is released, it tries to complete() uninitialized
completion.
Fix this by initializing the completion earlier.
Reported-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Closes: https://lore.kernel.org/linux-usb/amdezCBiW4fd_DuB@mail-itl/
Reported-by: Woody Suwalski <terraluna977@gmail.com>
Tested_by: Woody Suwalski <terraluna977@gmail.com>
Closes: https://lore.kernel.org/linux-usb/62caf7f8-b403-d0dd-15bc-b31b56f71c28@gmail.com/
Fixes: f5cc545f5969 ("thunderbolt: Wait for tb_domain_release() to complete when driver is removed")
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
|
|
Move NV_PBUS_SW_SCRATCH_0E_FRTS_ERR register definition into gsp
module and update registers visibility.
Suggested-by: Alexandre Courbot <acourbot@nvidia.com>
Suggested-by: Danilo Krummrich <dakr@kernel.org>
Signed-off-by: Antonin Malzieu Ridolfi <dev@nanonej.com>
Link: https://patch.msgid.link/20260727-nova-core-regs-split-v2-3-21b5e6e32ea5@nanonej.com
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
|
|
Move PFB registers definitions into fb module and update registers
visibility.
Suggested-by: Alexandre Courbot <acourbot@nvidia.com>
Suggested-by: Danilo Krummrich <dakr@kernel.org>
Signed-off-by: Antonin Malzieu Ridolfi <dev@nanonej.com>
Link: https://patch.msgid.link/20260727-nova-core-regs-split-v2-2-21b5e6e32ea5@nanonej.com
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
|
|
Create new function abstracting WPR2 region range query.
Refactor gsp hal tu102 to query the WPR2 region range using this new
function.
Suggested-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Antonin Malzieu Ridolfi <dev@nanonej.com>
Link: https://patch.msgid.link/20260727-nova-core-regs-split-v2-1-21b5e6e32ea5@nanonej.com
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
|
|
Add live KUnit coverage for the debug-controlled BO
page-size allocation modes.
The new tests cover forced 2M mode, forced 1G mode,
and mixed mode. They verify that user BO creation applies
the expected NEEDS_* flags, that no unexpected page-size flags are
added in the forced modes, that BO size is rounded as expected, and
that page_alignment matches the selected leaf size.
The mixed-mode test does not assume a strict per-allocation rotation
sequence, since the device-global mixed-mode index may be perturbed by
concurrent BO creation on a live system. Instead,
it validates that each allocation results in
one valid mixed-mode page-size outcome.
Treat transient VRAM allocation failures as skipped test cases so the
tests can run in varying live environments without producing false
failures.
v3
- address review comments
- rework mixed-mode test to avoid assuming strict rotation order
- reword commit message
v4
- skip VRAM-targeted live tests on non-dGFX devices
v5
- advance the mixed-mode index in the test
v6
- Gaurd kunit tests under CONFIG_DRM_XE_DEBUG_PAGE_SIZE
v9
- consider XE_VRAM_FLAGS_NEED64K in mixed mode for certain
platoform min alignment expectations.
Signed-off-by: Nareshkumar Gollakoti <naresh.kumar.g@intel.com>
Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
Link: https://patch.msgid.link/20260729121843.1255891-7-naresh.kumar.g@intel.com
Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
|