summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2026-05-07crypto: ccp - Fix snp_filter_reserved_mem_regions() off-by-oneTycho Andersen (AMD)
Sashiko notes: > regarding the bounds check in snp_filter_reserved_mem_regions() > called via walk_iomem_res_desc(): does the check > if ((range_list->num_elements * 16 + 8) > PAGE_SIZE) > allow an off-by-one heap buffer overflow? > > If range_list->num_elements is 255, 255 * 16 + 8 = 4088, which is <= 4096. > Writing range->base (8 bytes) fills 4088-4095, but writing range->page_count > (4 bytes) would write to 4096-4099, overflowing the kzalloc-allocated > PAGE_SIZE buffer. Fix this by accounting for the entry about to be written to, in addition to the entries that are already allocated. Fixes: 1ca5614b84ee ("crypto: ccp: Add support to initialize the AMD-SP for SEV-SNP") Reported-by: Sashiko Assisted-by: Gemini:gemini-3.1-pro-preview Link: https://sashiko.dev/#/patchset/20260324161301.1353976-1-tycho%40kernel.org Signed-off-by: Tycho Andersen (AMD) <tycho@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-05-07crypto: ccp - Reverse the cleanup order in psp_dev_destroy()Tycho Andersen (AMD)
Before SNP x86 shutdown [1], all HV_FIXED pages were always leaked on module unload. Now pages can be reclaimed if they are freed before SNP shutdown. The SFS driver does sfs_dev_destroy() -> snp_free_hv_fixed_pages(), marking the command buffer as free. But this happens after sev_dev_destroy() in psp_dev_destroy(), so the pages are always leaked. Rearrange psp_dev_destroy() to destroy things in the reverse order from psp_init(), so that any dependencies can be unwound accordingly. This lets SFS free the page and the subsequent SNP shutdown release it. This was identified with use of Chris Mason's review-prompts: https://github.com/masoncl/review-prompts [1]: https://lore.kernel.org/all/20260324161301.1353976-1-tycho@kernel.org/ Fixes: 648dbccc03a0 ("crypto: ccp - Add AMD Seamless Firmware Servicing (SFS) driver") Reported-by: review-prompts Assisted-by: Claude:claude-4.6-opus Suggested-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Tycho Andersen (AMD) <tycho@kernel.org> Reviewed-by: Ashish Kalra <ashish.kalra@amd.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-05-07gpio: amd8111: Drop useless zeros in array initialisationUwe Kleine-König (The Capable Hub)
The compiler fills in zeros as needed, so there is no technical reason to add explicit zeros at the end of a list initializer. Drop them. Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com> Link: https://patch.msgid.link/20260506144918.2445358-2-u.kleine-koenig@baylibre.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
2026-05-07drm/panthor: Fix missing declaration for panthor_transparent_hugepagegyeyoung
sparse reports: drivers/gpu/drm/panthor/panthor_drv.c:1805:6: warning: symbol 'panthor_transparent_hugepage' was not declared. Should it be static? Make it clean. Signed-off-by: gyeyoung <gye976@gmail.com> Reviewed-by: Steven Price <steven.price@arm.com> Signed-off-by: Steven Price <steven.price@arm.com> Link: https://patch.msgid.link/20260503144234.2150138-1-gye976@gmail.com
2026-05-07soundwire: use krealloc_array to prevent integer overflowBaoli.Zhang
Replace the use of krealloc() with krealloc_array() in sdw_add_element_group_count to mitigate the risk of integer overflow during memory allocation size calculation. Suggested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Baoli.Zhang <baoli.zhang@linux.intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/20260506055039.3751028-4-baoli.zhang@linux.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-05-07soundwire: increase group->max_size after allocationBaoli.Zhang
Only update `group->max_size` after both allocations succeed to avoid leaving the group's state inconsistent if one allocation fails. Signed-off-by: Baoli.Zhang <baoli.zhang@linux.intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/20260506055039.3751028-3-baoli.zhang@linux.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-05-07soundwire: fix bug in sdw_add_element_group_count found by syzkallerBaoli.Zhang
The original implementation caused an out-of-bounds memory access in the sdw_add_element_group_count for-loop when i == num. for (i = 0; i <= num; i++) { if (rate == group->rates[i] && lane == group->lanes[i]) ... To fix this error, the function now checks for existing rate/lane entries in the group(a function parameter) using a for-loop before adding them. No functional changes apart from this fix. Fixes: 9026118f20e2 ("soundwire: Add generic bandwidth allocation algorithm") Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Baoli.Zhang <baoli.zhang@linux.intel.com> Link: https://patch.msgid.link/20260506055039.3751028-2-baoli.zhang@linux.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-05-07soundwire: don't program SDW_SCP_BUSCLOCK_SCALE on a unattached PeripheralBard Liao
The SDW_SCP_BUSCLOCK_SCALE register will be programmed when the Peripheral is attached. We can and should skip programming the SDW_SCP_BUSCLOCK_SCALE register when the Peripheral is unattached. Fixes: 645291cfe5e5 ("Soundwire: stream: program BUSCLOCK_SCALE") Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Simon Trimmer <simont@opensource.cirrus.com> Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Link: https://patch.msgid.link/20260428084612.322701-1-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-05-06Merge tag 'chrome-platform-fixes-v7.1-rc3' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux Pull chrome-platform fix from Tzung-Bi Shih: - Fix a NULL dereference in cros_ec_typec * tag 'chrome-platform-fixes-v7.1-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux: platform/chrome: cros_ec_typec: Init mutex in Thunderbolt registration
2026-05-07OPP: Fix race between OPP addition and lookupDi Shen
A race exists between dev_pm_opp_add_dynamic() and dev_pm_opp_find_freq_exact(): CPU0 (add) CPU1 (lookup) ------------------------------- ------------------------------ _opp_add() mutex_lock() list_add(&new_opp->node, head) mutex_unlock() _opp_table_find_key() mutex_lock() dev_pm_opp_get(opp) kref_get() mutex_unlock() kref_init(&new_opp->kref) dev_pm_opp_put() kref_put_mutex() The newly added OPP is inserted into the list before its kref is initialized. A concurrent lookup can find this OPP and increment its reference count while it is still uninitialized, leading to refcount corruption and a potential premature free. Fix this by initializing ->kref and ->opp_table before making the OPP visible via list_add(). This ensures any concurrent lookup observes a fully initialized object. Fixes: 7034764a1e4a (PM / OPP: Add 'struct kref' to struct dev_pm_opp) Co-developed-by: Ling Xu <ling_ling.xu@unisoc.com> Signed-off-by: Ling Xu <ling_ling.xu@unisoc.com> Signed-off-by: Di Shen <di.shen@unisoc.com> [ Viresh: Updated commit log ] Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2026-05-06w5100: remove unused gpio link detectionArnd Bergmann
Since the platform_device support is now gone, nothing ever passes a valid gpio number, and all the link state handling can go away. An earlier version of my patch changed this to look up the GPIO descriptor from devicetree and convert it all to the modern interface, but there are no users of that binding at the moment. Remove the gpio handling, which is now one of the last users of the legacy gpio interface in platform-independent code. Cc: Rob Herring <robh@kernel.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/all/20230127095839.3266452-1-arnd@kernel.org/ Link: https://patch.msgid.link/20260505180459.1247690-3-arnd@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-06w5300: remove unused driverArnd Bergmann
Unlike w5100, this driver does not support SPI mode or devicetree bindings, and is hence entirely unusable without third-party board support patches that likely haven't existed for any recent kernel version. Remove the entire driver. If anyone is in fact using it with their custom board files, they can bring it back and include an earlier patch I sent to add DT based probing for the GPIO lines. Link: https://lore.kernel.org/all/20260427142924.2702598-1-arnd@kernel.org/ Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://patch.msgid.link/20260505180459.1247690-2-arnd@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-06w5100: remove MMIO supportArnd Bergmann
This driver supports both SPI and MMIO based register access, but only the former has devicetree support. While MMIO mode would have worked with old-style board files, those have never defined such a device upstream. Remove the MMIO mode, leaving SPI as the only way to use this driver, but leave it in two loadable modules. More cleanups can be done by combining the two into one file. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://patch.msgid.link/20260505180459.1247690-1-arnd@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-06net/mlx5: E-Switch, load reps via work queue after registrationMark Bloch
mlx5_eswitch_register_vport_reps() only installs representor callbacks and marks the rep type as registered. If the E-Switch is already in switchdev mode, the newly registered rep type must then be loaded for already enabled vports. That load path needs to run under the devlink lock, which is not held by the auxiliary driver registration context. Queue the reload to the E-Switch workqueue, whose handler acquires the devlink lock, and load the relevant representors from there. Since representor registration runs from sleepable auxiliary-driver context, queue the late reload with GFP_KERNEL. The functions-change notifier path remains the GFP_ATOMIC user of mlx5_esw_add_work(). The unregister path is unchanged and still unloads representors synchronously while tearing down the registered callbacks. Signed-off-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260503202726.266415-8-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-06net/mlx5: E-Switch, unwind only newly loaded representor typesMark Bloch
__esw_offloads_load_rep() may return success without invoking the representor load callback when the representor type is already loaded. On a later load failure, mlx5_esw_offloads_rep_load() unconditionally unloaded all previously iterated representor types. This could unload representor types that were already loaded before this load attempt. Track which representor types were actually loaded by the current call and unwind only those on error. Also restore the representor state back to REP_REGISTERED when the load callback itself fails. Signed-off-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260503202726.266415-7-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-06net/mlx5: E-Switch, serialize representor lifecycleMark Bloch
Representor callbacks can be registered and unregistered while the E-Switch is already in switchdev mode, and the same E-Switch may also be reconfigured by devlink, VF changes and SF changes. Serialize these paths with the per-E-Switch representor mutex instead of relying on ad-hoc bit state and wait queues. Take the representor lock around the mode transition, VF/SF representor changes and representor ops registration. Keep mode_lock and the representor lock unnested by using the operation flag while the mode lock is dropped. During mode changes, drop the representor lock around the auxiliary bus rescan because driver bind/unbind may register or unregister representor ops. Split representor ops registration into locked public wrappers and blocked internal helpers, clear the ops pointer on unregister, and add nested wrappers for the shared-FDB master IB path that registers peer representor ops while another E-Switch representor lock is already held. On unregister, always call __unload_reps_all_vport() before marking reps unregistered and clearing rep_ops. The per-representor state check makes this a no-op for types that were not loaded, so unregister no longer has to infer load state from esw->mode. Signed-off-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260503202726.266415-6-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-06net/mlx5: Lag, avoid LAG and representor lock cyclesMark Bloch
The LAG shared-FDB and multiport E-Switch transitions rescan auxiliary devices and reload IB representors while holding ldev->lock. Driver bind/unbind paths may register or unregister E-Switch representor ops, and representor load paths may enter LAG code, so holding ldev->lock across those calls creates lock-order cycles with the E-Switch representor lock. Keep the devcom component locked for the transition, but drop ldev->lock before rescanning auxiliary devices or reloading IB representors. Mark the LAG transition as in progress while the lock is dropped and assert the devcom lock where the helper relies on it. This preserves LAG serialization while avoiding ldev->lock nesting under E-Switch representor registration. Signed-off-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260503202726.266415-5-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-06net/mlx5: E-Switch, add representor lifecycle lockMark Bloch
Add a per-E-Switch mutex for serializing representor lifecycle work and provide small helpers for taking and dropping it. Initialize and destroy the mutex with the E-Switch offloads state. Add the lock and helper API first. Follow-up patches will take the lock in the individual representor lifecycle components. This keeps the functional changes split by component and leaves this patch without intended behavior change, making the series easier to review and bisectable. Signed-off-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260503202726.266415-4-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-06net/mlx5: E-Switch, let esw work callers choose GFP flagsMark Bloch
mlx5_esw_add_work() always allocates the queued work item with GFP_ATOMIC. That is required for the E-Switch functions-change notifier, but not every caller of this helper will run from atomic context. Pass an allocation flag to mlx5_esw_add_work() and keep the notifier caller using GFP_ATOMIC. This allows sleepable callers to use GFP_KERNEL instead of unnecessarily relying on atomic reserves. Signed-off-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260503202726.266415-3-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-06net/mlx5: Lag: refactor representor reload handlingMark Bloch
Representor reload during LAG/MPESW transitions has to be repeated in several flows, and each open-coded loop was easy to get out of sync when adding new flags or tweaking error handling. Move the sequencing into a single helper so that all call sites share the same ordering and checks. Signed-off-by: Mark Bloch <mbloch@nvidia.com> Reviewed-by: Shay Drori <shayd@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260503202726.266415-2-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-06r8152: Add firmware upload capability for RTL8157/RTL8159Birger Koblitz
The RTL8159 (RTL_VER_17) requires firmware for its PHY in order to work at connection speeds > 5GBit. Add support for uploading firmware for the PHY using the existing rtl8152_apply_firmware() function in r8157_hw_phy_cfg() and set up the correct names for the firmware files. This also adds support for uploading firmware for the RTL8157 (RTL_VER_16) PHY, for which firmware is however not strictly necessary to work. Still, this allows to upload newer versions of the firmware used by this chip, e.g. to improve interoperability. If no firmware is found, both the RTL8157 and the RTL8159 will continue to work. Signed-off-by: Birger Koblitz <mail@birger-koblitz.de> Tested-by: Aleksander Jan Bajkowski <olek2@wp.pl> Link: https://patch.msgid.link/20260505-rtl8159_net_next-v4-3-1a648a9c4d8d@birger-koblitz.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-06r8152: Add support for the RTL8159 chipBirger Koblitz
The RTL8159 re-uses the packet descriptor format introduced with the RTL8157 and other hardware features of the RTL8157 (RTL_VER_16) such as the SRAM access. The support therefore consists in expanding the existing RTL8157 code for initialization and USB power management to also be used for the RTL8159 (RTL_VER_17). Most of the additional code is added in r8157_hw_phy_cfg() to configure the RTL8159 PHY. Add support for the USB device ID of Realtek RTL8159-based adapters, for which the product ID is 0x815a. Detect the RTL8159 as RTL_VER_17 and set it up. Signed-off-by: Birger Koblitz <mail@birger-koblitz.de> Tested-by: Aleksander Jan Bajkowski <olek2@wp.pl> Link: https://patch.msgid.link/20260505-rtl8159_net_next-v4-2-1a648a9c4d8d@birger-koblitz.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-06r8152: Add support for 10Gbit Link Speeds and EEEBirger Koblitz
The RTL8159 supports 10GBit Link speeds. Add support for this speed in the setup and setting/getting through ethtool. Also add 10GBit EEE. Add functionality for setup and ethtool get/set methods. Signed-off-by: Birger Koblitz <mail@birger-koblitz.de> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Tested-by: Aleksander Jan Bajkowski <olek2@wp.pl> Link: https://patch.msgid.link/20260505-rtl8159_net_next-v4-1-1a648a9c4d8d@birger-koblitz.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-06net: ethernet: cortina: Drop half-assembled SKBAndreas Haarmann-Thiemann
In gmac_rx() (drivers/net/ethernet/cortina/gemini.c), when gmac_get_queue_page() returns NULL for the second page of a multi-page fragment, the driver logs an error and continues — but does not free the partially assembled skb that was being assembled via napi_build_skb() / napi_get_frags(). Free the in-progress partially assembled skb via napi_free_frags() and increase the number of dropped frames appropriately and assign the skb pointer NULL to make sure it is not lingering around, matching the pattern already used elsewhere in the driver. Fixes: 4d5ae32f5e1e ("net: ethernet: Add a driver for Gemini gigabit ethernet") Signed-off-by: Andreas Haarmann-Thiemann <eitschman@nebelreich.de> Signed-off-by: Linus Walleij <linusw@kernel.org> Reviewed-by: Alexander Lobakin <aleksander.lobakin@intel.com> Link: https://patch.msgid.link/20260505-gemini-ethernet-fix-v2-1-997c31d06079@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-06net/mlx5e: Report stop and wake TX queue statsGal Pressman
Report TX queue stop and wake statistics via the netdev queue stats API by mapping the existing stopped and wake counters to the stop and wake fields. Signed-off-by: Gal Pressman <gal@nvidia.com> Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260504183704.272322-6-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-06net/mlx5e: Report TX csum_none netdev statGal Pressman
Report TX csum_none statistic via the netdev queue stats API by mapping the existing csum_none counter to the csum_none field. Signed-off-by: Gal Pressman <gal@nvidia.com> Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260504183704.272322-5-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-06net/mlx5e: Report RX HW-GRO netdev statsGal Pressman
Report RX hardware GRO statistics via the netdev queue stats API by mapping the existing gro_packets, gro_bytes and gro_skbs counters to the hw_gro_wire_packets, hw_gro_wire_bytes and hw_gro_packets fields. Signed-off-by: Gal Pressman <gal@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260504183704.272322-4-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-06net/mlx5e: Report hw_gso_packets and hw_gso_bytes netdev statsGal Pressman
Report hardware GSO statistics via the netdev queue stats API by mapping the existing TSO counters to hw_gso_packets and hw_gso_bytes fields. Signed-off-by: Gal Pressman <gal@nvidia.com> Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260504183704.272322-3-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-06net/mlx5e: Count full skb length in TSO byte countersGal Pressman
The tso_bytes and tso_inner_bytes counters currently subtract the header length from skb->len, counting only the payload. This is confusing and doesn't align with the behavior of other _bytes counters in the driver. Report the full skb length to align with this expectation. This also makes our behavior consistent with the netdev stats API and virtio spec definition. Signed-off-by: Gal Pressman <gal@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260504183704.272322-2-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-06net: rtsn: fix mdio_node leak in rtsn_mdio_alloc()Shitalkumar Gandhi
of_get_child_by_name() takes a reference. The rtsn_reset() and rtsn_change_mode() failure paths jump to out_free_bus and leak mdio_node. Add out_put_node to drop it before falling through. Fixes: b0d3969d2b4d ("net: ethernet: rtsn: Add support for Renesas Ethernet-TSN") Signed-off-by: Shitalkumar Gandhi <shitalkumar.gandhi@cambiumnetworks.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Link: https://patch.msgid.link/20260505123236.406000-1-shitalkumar.gandhi@cambiumnetworks.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-06netdevsim: psp: rcu protect psp_dev referenceDaniel Zahka
There are two issues with the way psp_dev is used in nsim_do_psp(): 1. There is no check for IS_ERR() on the peers psp_dev, before dereferencing. 2. The refcount on this psp_dev can be dropped by nsim_psp_rereg_write() To fix this, we can make netdevsim's reference to its psp_dev an rcu reference, and then nsim_do_psp() can read the fields it needs from an rcu critical section. Fixes: f857478d6206 ("netdevsim: a basic test PSP implementation") Signed-off-by: Daniel Zahka <daniel.zahka@gmail.com> Reviewed-by: Willem de Bruijn <willemb@google.com> Link: https://patch.msgid.link/20260505-psd-rcu-v1-3-a8f69ec1ab96@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-06netdevsim: psp: serialize calls to nsim_psp_uninit()Daniel Zahka
The debugfs write handler, nsim_psp_rereg_write(), can race against nsim_destroy() and against itself, causing nsim_psp_uninit() to run more than once concurrently. Two complementary changes serialize all callers: 1. Delete the psp_rereg debugfs file from nsim_psp_uninit() before doing the actual teardown. debugfs_remove() drains any in-flight writers and prevents new ones from starting. 2. Add a mutex around the body of nsim_psp_rereg_write() so that two concurrent userspace writers cannot both enter the teardown path at once. The teardown work itself is moved into a new __nsim_psp_uninit() that the rereg handler calls under the mutex, while the public nsim_psp_uninit() wraps it with the debugfs_remove()/mutex_destroy() pair so nsim_destroy() doesn't have to know about the psp internals. Fixes: f857478d6206 ("netdevsim: a basic test PSP implementation") Signed-off-by: Daniel Zahka <daniel.zahka@gmail.com> Reviewed-by: Willem de Bruijn <willemb@google.com> Link: https://patch.msgid.link/20260505-psd-rcu-v1-2-a8f69ec1ab96@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-06netdevsim: psp: only call nsim_psp_uninit() on PFsDaniel Zahka
VFs go through nsim_init_netdevsim_vf() which never calls nsim_psp_init(), so ns->psp.dev stays NULL. nsim_psp_uninit() guards with !IS_ERR(ns->psp.dev), so destroying a VF reaches psp_dev_unregister(NULL) and dereferences NULL on the first mutex_lock(&psd->lock): BUG: kernel NULL pointer dereference, address: 0000000000000020 RIP: 0010:mutex_lock+0x1c/0x30 Call Trace: psp_dev_unregister+0x2a/0x1a0 nsim_psp_uninit+0x1f/0x40 [netdevsim] nsim_destroy+0x61/0x1e0 [netdevsim] __nsim_dev_port_del+0x47/0x90 [netdevsim] nsim_drv_configure_vfs+0xc9/0x130 [netdevsim] nsim_bus_dev_numvfs_store+0x79/0xb0 [netdevsim] Gate nsim_psp_uninit() on nsim_dev_port_is_pf(), matching the pattern already used for nsim_exit_netdevsim() and the bpf/ipsec/macsec/queue teardowns. Reproducer: modprobe netdevsim echo "10 1" > /sys/bus/netdevsim/new_device echo 1 > /sys/bus/netdevsim/devices/netdevsim10/sriov_numvfs devlink dev eswitch set netdevsim/netdevsim10 mode switchdev echo 0 > /sys/bus/netdevsim/devices/netdevsim10/sriov_numvfs Fixes: f857478d6206 ("netdevsim: a basic test PSP implementation") Signed-off-by: Daniel Zahka <daniel.zahka@gmail.com> Reviewed-by: Willem de Bruijn <willemb@google.com> Link: https://patch.msgid.link/20260505-psd-rcu-v1-1-a8f69ec1ab96@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-06rtase: Fix flow control configurationJustin Lai
The hardware has two sets of registers controlling TX/RX flow control. The effective flow control state is determined by the logical OR of these two sets of bits. RTASE_FORCE_TXFLOW_EN and RTASE_FORCE_RXFLOW_EN in RTASE_CPLUS_CMD are the bits used by the driver to control TX/RX flow control according to the ethtool pause configuration. RTASE_TXFLOW_EN and RTASE_RXFLOW_EN in RTASE_GPHY_STD_00 are another set of TX/RX flow control enable bits. Clear them by default so they do not keep flow control enabled independently of the driver setting. With the RTASE_GPHY_STD_00 bits cleared, the effective flow control state is controlled through RTASE_CPLUS_CMD, so the ethtool setting can take effect correctly. Signed-off-by: Justin Lai <justinlai0215@realtek.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20260505064121.31286-1-justinlai0215@realtek.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-07Merge tag 'amd-drm-next-7.2-2026-05-06' of ↵Dave Airlie
https://gitlab.freedesktop.org/agd5f/linux into drm-next amd-drm-next-7.2-2026-05-06: amdgpu: - GFX9 fixes - Hawaii SMU fixes - SDMA4 fix - GART fixes - Userq fixes - Finish support for using multiple SDMA queues for TTM operations - SWSMU updates - Misc cleanups and fixes - GC 12.1 updates - RAS updates - SMU 15.0.8 updates - DCN 4.2 updates - DC type conversion fixes - Enable DC power module - Replay/PSR updates - SMU 13.x updates - Compute queue quantum MQD updates - ASPM fix - GPUVM fixes - DCE 6 fixes - Align VKMS with common implementation - RDNA 4 fix - DC analog support fixes - UVD 3 fixes - TCC harvesting fixes for SI - GC 11 APU module reload fix - NBIO 6.3.2 support - IH 7.1 updates - DC cursor fixes - VCN user fence fixes - JPEG user fence fixes - DC support for connectors without DDC - Prefer ROM BAR for default VGA device - DC bandwidth fixes amdkfd: - GPUVM TLB flush fix - Hotplug fix - Boundary check fixes - Misc cleanups and fixes - SVM fixes - CRIU fixes radeon: - Hawaii SMU fixes - Misc cleanups and fixes From: Alex Deucher <alexander.deucher@amd.com> Link: https://patch.msgid.link/20260506164726.1733646-1-alexander.deucher@amd.com Signed-off-by: Dave Airlie <airlied@redhat.com>
2026-05-06Merge tag 'ovpn-net-20260504' of https://github.com/OpenVPN/ovpn-net-nextJakub Kicinski
Antonio Quartulli says: ==================== Includes changes: * ensure MAC header offset is reset before delivering packet * ensure gro_cells_receive() and dstats_dev_add() are called with BH disabled * reduce ping count in selftest to ensure it completes within timeout * tag 'ovpn-net-20260504' of https://github.com/OpenVPN/ovpn-net-next: selftests: ovpn: reduce ping count in test.sh ovpn: ensure packet delivery happens with BH disabled ovpn: reset MAC header before passing skb up ==================== Link: https://patch.msgid.link/20260504230305.2681646-1-antonio@openvpn.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-07firmware_loader: fix device reference leak in firmware_upload_register()Guangshuo Li
firmware_upload_register() -> fw_create_instance() -> device_initialize() After fw_create_instance() succeeds, the lifetime of the embedded struct device is expected to be managed through the device core reference counting, since fw_create_instance() has already called device_initialize(). In firmware_upload_register(), if alloc_lookup_fw_priv() fails after fw_create_instance() succeeds, the code reaches free_fw_sysfs and frees fw_sysfs directly instead of releasing the device reference with put_device(). This may leave the reference count of the embedded struct device unbalanced, resulting in a refcount leak. The issue was identified by a static analysis tool I developed and confirmed by manual review. Fix this by using put_device(fw_dev) in the failure path and letting fw_dev_release() handle the final cleanup, instead of freeing the instance directly from the error path. Fixes: 97730bbb242c ("firmware_loader: Add firmware-upload support") Cc: stable@vger.kernel.org Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com> Link: https://patch.msgid.link/20260505091231.607089-1-lgs201920130244@gmail.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-05-06PCI: Bail out early for 2.5GT/s devices in PCIe failed link retrainingMaciej W. Rozycki
There's no point in retraining a failed 2.5GT/s device at 2.5GT/s, so just don't and return early. While such devices might be unlikely to implement Link Active reporting, we need to retrieve the maximum link speed and use it in a conditional later on anyway, so the early check comes for free. Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Tested-by: Alok Tiwari <alok.a.tiwari@oracle.com> Link: https://patch.msgid.link/alpine.DEB.2.21.2512080356070.49654@angie.orcam.me.uk
2026-05-06PCI: Use pcie_get_speed_cap() in PCIe failed link retrainingMaciej W. Rozycki
Rewrite a check for the maximum link speed in the Link Capabilities register in terms of pcie_get_speed_cap(). No functional change. Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Tested-by: Alok Tiwari <alok.a.tiwari@oracle.com> Link: https://patch.msgid.link/alpine.DEB.2.21.2512080348310.49654@angie.orcam.me.uk
2026-05-06PCI: Always lift 2.5GT/s restriction in PCIe failed link retrainingMaciej W. Rozycki
Discard Vendor:Device ID matching in the PCIe failed link retraining quirk and ignore the link status for the removal of the 2.5GT/s speed clamp, whether applied by the quirk itself or the firmware earlier on. Revert to the original target link speed if this final link retraining has failed. This is so that link training noise in hot-plug scenarios does not make a link remain clamped to the 2.5GT/s speed where an event race has led the quirk to apply the speed clamp for one device, only to leave it in place for a subsequent device to be plugged in. Refer to the Link Capabilities register directly for the maximum link speed determination so as to streamline backporting. Fixes: a89c82249c37 ("PCI: Work around PCIe link training failures") Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Tested-by: Alok Tiwari <alok.a.tiwari@oracle.com> Cc: stable@vger.kernel.org # v6.5+ Link: https://patch.msgid.link/alpine.DEB.2.21.2512080331530.49654@angie.orcam.me.uk
2026-05-06Bluetooth: virtio_bt: validate rx pkt_type header lengthMichael Bommarito
virtbt_rx_handle() reads the leading pkt_type byte from the RX skb and forwards the remainder to hci_recv_frame() for every event/ACL/SCO/ISO type, without checking that the remaining payload is at least the fixed HCI header for that type. After the preceding patch bounds the backend-supplied used.len to [1, VIRTBT_RX_BUF_SIZE], a one-byte completion still reaches hci_recv_frame() with skb->len already pulled to 0. If the byte happened to be HCI_ACLDATA_PKT, the ACL-vs-ISO classification fast-path in hci_dev_classify_pkt_type() dereferences hci_acl_hdr(skb)->handle whenever the HCI device has an active CIS_LINK, BIS_LINK, or PA_LINK connection, reading two bytes of uninitialized RX-buffer data. The same hazard exists for every packet type the driver accepts because none of the switch cases in virtbt_rx_handle() check skb->len against the per-type minimum HCI header size before handing the frame to the core. After stripping pkt_type, require skb->len to cover the fixed header size for the selected type (event 2, ACL 4, SCO 3, ISO 4) before calling hci_recv_frame(); drop ratelimited otherwise. Unknown pkt_type values still take the original kfree_skb() default path. Use bt_dev_err_ratelimited() because both the length and pkt_type values come from an untrusted backend that can otherwise flood the kernel log. Fixes: 160fbcf3bfb9 ("Bluetooth: virtio_bt: Use skb_put to set length") Cc: stable@vger.kernel.org Cc: Soenke Huster <soenke.huster@eknoes.de> Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com> Assisted-by: Claude:claude-opus-4-7 Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-05-06Bluetooth: virtio_bt: clamp rx length before skb_putMichael Bommarito
virtbt_rx_work() calls skb_put(skb, len) where len comes directly from virtqueue_get_buf() with no validation against the buffer we posted to the device. The RX skb is allocated in virtbt_add_inbuf() and exposed to virtio as exactly 1000 bytes via sg_init_one(). Checking len against skb_tailroom(skb) is not sufficient because alloc_skb() can leave more tailroom than the 1000 bytes actually handed to the device. A malicious or buggy backend can therefore report used.len between 1001 and skb_tailroom(skb), causing skb_put() to include uninitialized kernel heap bytes that were never written by the device. The same path also accepts len == 0, in which case skb_put(skb, 0) leaves the skb empty but virtbt_rx_handle() still reads the pkt_type byte from skb->data, consuming uninitialized memory. Define VIRTBT_RX_BUF_SIZE once and reuse it in alloc_skb() and sg_init_one(), and gate virtbt_rx_work() on that same constant so the bound checked matches the buffer actually exposed to the device. Reject used.len == 0 in the same gate so an empty completion can no longer reach virtbt_rx_handle(). Use bt_dev_err_ratelimited() because the length value comes from an untrusted backend that can otherwise flood the kernel log. Same class of bug as commit c04db81cd028 ("net/9p: Fix buffer overflow in USB transport layer"), which hardened the USB 9p transport against unchecked device-reported length. Fixes: 160fbcf3bfb9 ("Bluetooth: virtio_bt: Use skb_put to set length") Cc: stable@vger.kernel.org Cc: Soenke Huster <soenke.huster@eknoes.de> Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com> Assisted-by: Claude:claude-opus-4-7 Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-05-06Bluetooth: btmtk: validate WMT event SKB length before struct accessTristan Madani
btmtk_usb_hci_wmt_sync() casts the WMT event response SKB data to struct btmtk_hci_wmt_evt (7 bytes) and struct btmtk_hci_wmt_evt_funcc (9 bytes) without first checking that the SKB contains enough data. A short firmware response causes out-of-bounds reads from SKB tailroom. Use skb_pull_data() to validate and advance past the base WMT event header. For the FUNC_CTRL case, pull the additional status field bytes before accessing them. Fixes: d019930b0049 ("Bluetooth: btmtk: move btusb_mtk_hci_wmt_sync to btmtk.c") Cc: stable@vger.kernel.org Signed-off-by: Tristan Madani <tristan@talencesecurity.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-05-06Bluetooth: hci_uart: Fix NULL deref in recv callbacks when priv is uninitializedAurelien DESBRIERES
When a fault is injected during hci_uart line discipline setup, the proto open() callback may fail leaving hu->priv as NULL. A subsequent TIOCSTI ioctl can trigger the recv() callback before priv is initialized, causing a NULL pointer dereference. Fix all four affected HCI UART protocol drivers by adding a NULL check on hu->priv at the start of their recv() callbacks: h4, h5, ath and bcsp. Reported-by: syzbot+ff30eeab8e07b37d524e@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=ff30eeab8e07b37d524e Signed-off-by: Aurelien DESBRIERES <aurelien@hackers.camp> Assisted-by: Claude:claude-sonnet-4-6 Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-05-06Bluetooth: btintel_pcie: treat boot stage bit 12 as warningSai Teja Aluvala
CSR boot stage register bit 12 is documented as a device warning, not a fatal error. Rename the bit definition accordingly and stop including it in btintel_pcie_in_error(). This keeps warning-only boot stage values from being classified as errors while preserving abort-handler state as the actual error condition. Fixes: 190377500fde ("Bluetooth: btintel_pcie: Dump debug registers on error") Signed-off-by: Kiran K <kiran.k@intel.com> Signed-off-by: Sai Teja Aluvala <aluvala.sai.teja@intel.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-05-06Merge tag 'parisc-for-7.1-rc3' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux Pull parisc fixes from Helge Deller: - Revert "parisc: led: fix reference leak on failed device registration" - Fix build failures introduced when allowing to build 32-/64-bit only VDSO - Switch to dynamic parisc root device to avoid upcoming warnings - Fix IRQ leak in LASI driver * tag 'parisc-for-7.1-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux: parisc: Fix IRQ leak in LASI driver parisc: Fix 64-bit kernel build when CONFIG_COMPAT=n parisc: Fix build failure for 32-bit kernel with PA2.0 instruction set parisc: drivers: switch to dynamic root device Revert "parisc: led: fix reference leak on failed device registration"
2026-05-06firmware: raspberrypi: Change dependency to ARCH_BCM2835 and COMPILE_TESTChen-Yu Tsai
The Raspberry Pi firmware driver has no compile dependencies on the BCM2835 mailbox driver. It's just a indirect runtime dependency: the driver only works on a Raspberry Pi. Change the dependency from BCM2835_MBOX to ARCH_BCM2835. Also allow compile tests. This allows drivers that have build time dependencies on this firmware driver to be compile tested as well. More dependencies are added to account for build time dependencies: - depends on MAILBOX for mailbox API (not stubbed) usage - depends on ARM || ARM64 for dsb() usage Also make it built by default if ARCH_BCM2835, since many functions will not work without this firmware driver. Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> Link: https://lore.kernel.org/r/20260427091058.2669812-1-wenst@chromium.org Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
2026-05-06soc: brcmstb: consolidate initcall functionsJustin Chen
Merge the separate early_initcall and arch_initcall functions into a single early_initcall. This is possible thanks to commit 6e12db376b60 ("base: soc: Allow early registration of a single SoC device"), which allows soc_device_register() to be called during early_initcall by deferring the actual registration until the soc_bus is ready. Replace static family_id/product_id variables with a dynamically allocated brcmstb_soc_info structure. Signed-off-by: Justin Chen <justin.chen@broadcom.com> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Tested-by: Florian Fainelli <florian.fainelli@broadcom.com> Link: https://lore.kernel.org/r/20260325174619.3761964-1-justin.chen@broadcom.com Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
2026-05-06drm/xe: Respect pin_params.alignment for GGTTVille Syrjälä
Fix __xe_pin_fb_vma_ggtt() to actually respect the GGTT alignment specified by the display code. Misalignment can cause GTT faults etc. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260430154602.11393-2-ville.syrjala@linux.intel.com Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
2026-05-06drm/xe: Use fb cached min alignmentTvrtko Ursulin
Instead of just looking at the first plane use the fb cached overall minimum alignment. This aligns with how the i915 version of intel_plane_pin_fb works. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> [vsyrjala: Rebase due to pin_params] Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260430154602.11393-1-ville.syrjala@linux.intel.com Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
generated by cgit v1.2.3 (git 2.39.1) at 2026-08-09 14:02:39 +0000