summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2026-06-06wifi: ath9k: Clear DMA descriptors without memsetRosen Penev
Clear ath9k DMA descriptors with explicit status word stores instead of memset(). The descriptor rings are coherent DMA memory, which may be mapped uncached on 32-bit powerpc. The optimized memset() path can use dcbz there and trigger an alignment warning. Use WRITE_ONCE() for the descriptor status words so the compiler keeps the clears as ordinary stores instead of folding them back into bulk memset(). This covers AR9003 TX status descriptors as well as the RX status area cleared when setting up RX descriptors. Assisted-by: Codex:GPT-5.5 Signed-off-by: Rosen Penev <rosenp@gmail.com> Acked-by: Toke Høiland-Jørgensen <toke@toke.dk> Link: https://patch.msgid.link/20260517042716.2218386-1-rosenp@gmail.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-06-06wifi: ath9k_htc: use module_usb_driverRosen Penev
This follows the pattern with other USB Wifi drivers. There is nothing special being done in the _init and _exit functions here. Simplifies and saves some lines of code. Signed-off-by: Rosen Penev <rosenp@gmail.com> Acked-by: Toke Høiland-Jørgensen <toke@toke.dk> Link: https://patch.msgid.link/20260506234848.189840-1-rosenp@gmail.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-06-06wifi: wcn36xx: allocate chan_surveys with main structRosen Penev
Avoid allocating separately with a flexible array member. Simplifies allocation slightly. Signed-off-by: Rosen Penev <rosenp@gmail.com> Reviewed-by: Loic Poulain <loic.poulain@oss.qualcomm.com> Link: https://patch.msgid.link/20260519020317.635011-1-rosenp@gmail.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-06-06wifi: wcn36xx: fix spelling mistakes in dxe header commentStepan Ionichev
Fix three spelling mistakes in the DMA Transfer Engine (DXE) description comment at the top of dxe.c. No functional change. Signed-off-by: Stepan Ionichev <sozdayvek@gmail.com> Link: https://patch.msgid.link/20260503165832.1675-1-sozdayvek@gmail.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-06-06wifi: wcn36xx: fix OOB read from short trigger BA firmware responseTristan Madani
The firmware response length is only checked against sizeof(*rsp) (20 bytes), but when candidate_cnt >= 1, a 22-byte candidate struct is read at buf + 20 without verifying the response contains it. This causes an out-of-bounds read of stale heap data, corrupting the BA session state. Add validation that the response includes the candidate data. Fixes: 16be1ac55944 ("wcn36xx: Parse trigger_ba response properly") Signed-off-by: Tristan Madani <tristan@talencesecurity.com> Reviewed-by: Loic Poulain <loic.poulain@oss.qualcomm.com> Link: https://patch.msgid.link/20260421135018.352774-4-tristmd@gmail.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-06-06wifi: wcn36xx: fix OOB read from firmware count in PRINT_REG_INFO indicationTristan Madani
The firmware-controlled rsp->count field is used as the loop bound for indexing into the flexible rsp->regs[] array without validation against the message length. A count exceeding the actual data causes out-of- bounds reads from the heap-allocated message buffer. Add a check that count fits within the received message. Fixes: 43efa3c0f241 ("wcn36xx: Implement print_reg indication") Signed-off-by: Tristan Madani <tristan@talencesecurity.com> Reviewed-by: Loic Poulain <loic.poulain@oss.qualcomm.com> Link: https://patch.msgid.link/20260421135018.352774-3-tristmd@gmail.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-06-06wifi: wcn36xx: fix heap overflow from oversized firmware HAL responseTristan Madani
The firmware response dispatcher copies all synchronous HAL responses into the 4096-byte hal_buf without validating the response length. A response exceeding WCN36XX_HAL_BUF_SIZE causes a heap buffer overflow with firmware-controlled content. Add a bounds check on the response length. Fixes: 8e84c2582169 ("wcn36xx: mac80211 driver for Qualcomm WCN3660/WCN3680 hardware") Signed-off-by: Tristan Madani <tristan@talencesecurity.com> Reviewed-by: Loic Poulain <loic.poulain@oss.qualcomm.com> Link: https://patch.msgid.link/20260421135018.352774-2-tristmd@gmail.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-06-05net: stmmac: xgmac: report L3/L4 filter match count in ethtool statsNazim Amirul
Read the L3FM and L4FM bits from the RX descriptor status word (RDES2) and increment the corresponding ethtool statistics counters. This allows users to observe L3/L4 filter hit rates via ethtool -S. Signed-off-by: Rohan G Thomas <rohan.g.thomas@altera.com> Signed-off-by: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Link: https://patch.msgid.link/20260604083037.24407-1-muhammad.nazim.amirul.nazle.asmade@altera.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-05net: microchip: sparx5: clean up PSFP resources on flower setup failureHaoxiang Li
sparx5_tc_flower_psfp_setup() allocates PSFP stream gate, flow meter and stream filter resources before adding VCAP actions. If a later step fails, the resources allocated earlier in the function are not unwound. Add error paths to release the stream filter, flow meter and stream gate when setup fails after they have been acquired. Also make sparx5_psfp_fm_add() return the acquired flow-meter id before the existing-flow-meter early return. When an existing flow meter is reused, sparx5_psfp_fm_get() increments its pool reference count, but the caller previously kept psfp_fmid as 0. If a later setup step failed, the error path could try to delete flow-meter id 0 instead of the reused flow meter, leaving the incremented reference behind. Signed-off-by: Haoxiang Li <lihaoxiang@isrc.iscas.ac.cn> Link: https://patch.msgid.link/20260603061716.747282-1-lihaoxiang@isrc.iscas.ac.cn Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-05net: airoha: Support multiple LAN/WAN interfaces for hw MAC address ↵Lorenzo Bianconi
configuration The EN7581 and AN7583 SoCs provide registers to configure hardware LAN/WAN MAC addresses. These registers are used during FE hw acceleration to determine whether received traffic is destined to this host (L3 traffic) or should be switched to another device (L2 traffic). The SoC hardware design assumes all interfaces configured as LAN (or WAN) share the MAC address MSBs, which are programmed into the REG_FE_{LAN,WAN}_MAC_H register. The LSBs of 'local' mac addresses can be expressed as a range via the REG_FE_MAC_LMIN and REG_FE_MAC_LMAX registers. In order to properly accelerate the traffic, FE module requires the user to configure the REG_FE_{LAN,WAN}_MAC_H register respecting this limitation. Please note a misconfiguration in REG_FE_{LAN,WAN}_MAC_H will still allow the user to log into the device for debugging. Previously, only a single interface was considered when programming these registers. Extend the logic to derive the correct minimum and maximum values for REG_FE_MAC_LMIN/REG_FE_MAC_LMAX when two or more interfaces are configured as LAN or WAN. Since this functionality was not available before this series, no regression is introduced. Tested-by: Madhur Agrawal <madhur.agrawal@airoha.com> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://patch.msgid.link/20260603-airoha-eth-multi-serdes-v9-6-5d476bc2f426@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-05net: airoha: Introduce WAN device flagLorenzo Bianconi
Introduce WAN flag to specify if a given device is used to transmit/receive WAN or LAN traffic. Current codebase supports specifying LAN/WAN device configuration in ndo_init() callback during device bootstrap. In order to consider setups where LAN configuration is used even for GDM3/GDM4 devices, check airoha_is_lan_gdm_dev() to select pse_port in airoha_ppe_foe_entry_prepare(). Please note after this patch, it will be possible to specify multiple LAN devices but just a single WAN one. Please note this change is not visible to the user since airoha_eth driver currently supports just the internal phy available via the MT7530 DSA switch and there are no WAN interfaces officially supported since PCS/external phy is not merged mainline yet (it will be posted with following patches). Tested-by: Xuegang Lu <xuegang.lu@airoha.com> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://patch.msgid.link/20260603-airoha-eth-multi-serdes-v9-5-5d476bc2f426@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-05net: airoha: Do not stop GDM port if it is sharedLorenzo Bianconi
Theoretically, in the current codebase, two independent net_devices can be connected to the same GDM port so we need to check the GDM port is not used by any other running net_device before setting the forward configuration to FE_PSE_PORT_DROP. Moreover, always set in GDM_LONG_LEN_MASK field of REG_GDM_LEN_CFG register the maximum MTU of all running net_devices connected to the same GDM port. Tested-by: Xuegang Lu <xuegang.lu@airoha.com> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://patch.msgid.link/20260603-airoha-eth-multi-serdes-v9-4-5d476bc2f426@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-05net: airoha: Support multiple net_devices for a single FE GDM portLorenzo Bianconi
EN7581 or AN7583 SoCs support connecting multiple external SerDes (e.g. Ethernet or USB SerDes) to GDM3 or GDM4 ports via a hw arbiter that manages the traffic in a TDM manner. As a result multiple net_devices can connect to the same GDM{3,4} port and there is a theoretical "1:n" relation between GDM ports and net_devices. ┌─────────────────────────────────┐ │ │ ┌──────┐ │ P1 GDM1 ├────►MT7530│ │ │ └──────┘ │ │ ETH0 (DSA conduit) │ │ │ PSE/FE │ │ │ │ │ │ │ ┌─────┐ │ P0 CDM1 ├────►QDMA0│ │ P4 P9 GDM4 │ └─────┘ └──┬─────────────────────────┬────┘ │ │ ┌──▼──┐ ┌────▼────┐ │ PPE │ │ ARB │ └─────┘ └─┬─────┬─┘ │ │ ┌──▼──┐┌─▼───┐ │ ETH ││ USB │ └─────┘└─────┘ ETH1 ETH2 Introduce support for multiple net_devices connected to the same Frame Engine (FE) GDM port (GDM3 or GDM4) via an external hw arbiter. Please note GDM1 or GDM2 does not support the connection with the external arbiter. Add get_dev_from_sport callback since EN7581 and AN7583 have different logics for the net_device type connected to GDM3 or GDM4. Tested-by: Xuegang Lu <xuegang.lu@airoha.com> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://patch.msgid.link/20260603-airoha-eth-multi-serdes-v9-3-5d476bc2f426@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-05net: airoha: Remove private net_device pointer in airoha_gdm_dev structLorenzo Bianconi
Remove redundant net_device pointer inside airoha_gdm_dev struct and rely on netdev_from_priv routine instead. Please note this patch does not introduce any logical change, just code refactoring. Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://patch.msgid.link/20260603-airoha-eth-multi-serdes-v9-2-5d476bc2f426@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-05net: mdio: realtek-rtl9300: Correctly handle ethernet-phy-packageManuel Stocker
Realtek Otto switches usually make use of multiport PHYs (e.g. 8 port 1G RTL8218D or 4 port 2.5G RTL8224). The device tree can describe this fact via an "ethernet-phy-package" node that resides between the bus and the PHY node. When looking up the device tree bus node via the chain port->phy->parent the driver totally ignores the existence of a PHY package. Enhance the lookup to take care of this feature. Link: https://github.com/openwrt/openwrt/pull/23591 Signed-off-by: Manuel Stocker <mensi@mensi.ch> Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de> Link: https://patch.msgid.link/20260603175924.123019-8-markus.stockhausen@gmx.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-05net: mdio: realtek-rtl9300: reorder controller setupMarkus Stockhausen
After the former refactoring the existing otto_emdio_9300_mdiobus_init() contains only the c22/c45 bus mode setup. Like the topology setup this must run before bus registration. Otherwise the bus does not "speak" the right protocol for PHY setup. This setup is device-specific and other SoCs will need to set up other register bits in the controller in the future. Therefore - Relocate c22/c45 device tree readout to the very beginning of the probing - Add a new device-specific setup_controller() into the info structure. - Relocate otto_emdio_priv to satisfy the new info structure dependency. - Rename otto_emdio_9300_mdiobus_init accordingly and add it to the RTL9300 info structure. At the same time, adapt register naming for the function to make it clear that it only applies to this SoC. - Call setup_controller() prior to bus registration. Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de> Link: https://patch.msgid.link/20260603175924.123019-7-markus.stockhausen@gmx.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-05net: mdio: realtek-rtl9300: relocate c22/c45 device tree readoutMarkus Stockhausen
otto_emdio_map_ports() is the central place to lookup the topology and the properties of the Realtek ethernet MDIO controller from the device tree. Deviating from this the c22/c45 detection via "ethernet-phy-ieee802.3-c45" is running separately in otto_emdio_probe_one(). It loops over the same nodes, just at a later point in time. There is no benefit to divide this setup and to have a time window where the data structure is only filled partially. Additionally it uses the "fwnode" API. Consolidate the setup and convert it to the "of" API. Remark. This is a subtle change for dangling PHY nodes (not referenced by ethernet-ports). Before this commit all PHY nodes were evaluated for c45 setup, now only the referenced ones. Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de> Link: https://patch.msgid.link/20260603175924.123019-6-markus.stockhausen@gmx.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-05net: mdio: realtek-rtl9300: relocate topology setupMarkus Stockhausen
Until now the driver sets up the port to bus/address topology of the controller after all buses are set up via otto_emdio_probe_one(). This does not work for devices where U-Boot skips this setup. It is not only needed for the hardware internal background PHY polling engine but it is essential for access to the PHYs during probing. Depending on the SoC type there exist two different register arrays - Bus mapping registers (RTL930x, RTL931x) define to which bus the port is attached. E.g. [1] - Address mapping registers (RTL838x, RTL930x, RTL931x) define to which address of the bus the port is attached. E.g. [2] Relocate the topology setup and make it generic. For this - Define device-specific bus_base/addr_base attributes that give the register base address where the mapping lives. In case one or both are not given the SoC does not support this specific type of mapping. - Create a helper otto_emdio_setup_topology() that writes the detected topology to the registers. - Call this helper prior to otto_emdio_probe_one(). - Remove unneeded code from otto_emdio_9300_mdiobus_init(). - Due to the added prefixes, increase define indentation Subtle change: The old coding used regmap_bulk_write and silently wrote bus=0/address=0 to mapping registers for ports that are out of scope. The new coding leaves those untouched. [1] https://svanheule.net/realtek/longan/register/smi_port0_15_polling_sel [2] https://svanheule.net/realtek/longan/register/smi_port0_5_addr_ctrl Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de> Link: https://patch.msgid.link/20260603175924.123019-5-markus.stockhausen@gmx.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-05net: mdio: realtek-rtl9300: harden otto_emdio_probe_one()Markus Stockhausen
The bus probing of the MDIO driver uses a two stage approach. 1. The device tree "ethernet-ports" node is scanned to build a mapping between ports and PHYs. 2. The children of the device tree "controller" are scanned to create the individual MDIO buses. The first step already checks the consistency of the PHY and bus nodes that are linked via the ports. But it might miss a dangling bus child node that is not linked. Step two simply iterates over all bus child nodes and might read malformed data from nodes not checked in step one. Harden this and return a meaningful error message. Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de> Link: https://patch.msgid.link/20260603175924.123019-4-markus.stockhausen@gmx.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-05net: mdio: realtek-rtl9300: harden otto_emdio_map_ports()Markus Stockhausen
Due to its design the MDIO driver needs to set up a port to bus/address mapping during probing. The "ethernet-ports" subnodes are scanned and from the "phy-handle" property the MDIO nodes are looked up. In case of a malformed device tree the driver might produce out-of-bounds accesses. The PHY address is not checked against the maximum supported address. Add a sanity check and drop the unneeded MAX_SMI_ADDR define. Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de> Link: https://patch.msgid.link/20260603175924.123019-3-markus.stockhausen@gmx.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-05net: mdio: realtek-rtl9300: Refactor otto_emdio_map_ports()Markus Stockhausen
This function has multiple issues: - It uses __free low level cleanups - It mixes "fwnode" and "of" functions Convert this to a uniform "of" usage and manual reference counting cleanup. With that also fix two subtle lookup bugs in the original code. mdio_dn = phy_dn->parent; if (mdio_dn->parent != dev->of_node) continue; This skips an API access and therefore misses reference counting. Additionally in the case of a very buggy device tree, phy_dn might be a root node. Looking up its grandparent leads to a NULL pointer access. Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de> Link: https://patch.msgid.link/20260603175924.123019-2-markus.stockhausen@gmx.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-05bnge: fix context mem iterationVikas Gupta
The firmware advertises context memory (backing store) types through a linked list, with BNGE_CTX_INV serving as the end-of-list sentinel. However, the driver incorrectly assumes that the list is strictly ordered and prematurely terminates traversal when it encounters an unrecognized type (>=BNGE_CTX_V2_MAX). As a result, any valid context types that appear later in the chain are silently skipped, leading to incomplete memory configuration and eventual driver load failure. Fix this by traversing the entire list until the BNGE_CTX_INV sentinel is reached, while safely ignoring only those context types that fall outside the supported range. Fixes: 29c5b358f385 ("bng_en: Add backing store support") Signed-off-by: Vikas Gupta <vikas.gupta@broadcom.com> Reviewed-by: Dharmender Garg <dharmender.garg@broadcom.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-05net: stmmac: dwmac4: Report DCB feature capabilityOvidiu Panait
Bit 16 of the MAC HW Feature1 register reports the DCB (Data Centre Bridging) feature. Read it so that dma_cap.dcben and the debugfs report it accurately. Right now it is always reported as being disabled. Signed-off-by: Ovidiu Panait <ovidiu.panait.rb@renesas.com> Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Link: https://patch.msgid.link/20260603173644.24371-1-ovidiu.panait.rb@renesas.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-05net: ena: PHC: Add missing barrierArthur Kiyanovski
Add dma_rmb() barrier after req_id completion check in ena_com_phc_get_timestamp(). On weakly-ordered architectures, payload fields may be read before req_id is observed as updated. Fixes: e0ea34158ee8 ("net: ena: Add PHC support in the ENA driver") Closes: https://sashiko.dev/#/patchset/20260430032507.11586-1-akiyano%40amazon.com Signed-off-by: Arthur Kiyanovski <akiyano@amazon.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-05net: airoha: Add NULL check for of_reserved_mem_lookup() in ↵ZhaoJinming
airoha_qdma_init_hfwd_queues() of_reserved_mem_lookup() may return NULL if the reserved memory region referenced by the "memory-region" phandle is not found in the reserved memory table (e.g. due to a misconfigured DTS or a removed memory-region node). The current code dereferences the returned pointer without checking for NULL, leading to a kernel NULL pointer dereference at the following lines: dma_addr = rmem->base; // line 1156 num_desc = div_u64(rmem->size, buf_size); // line 1160 Add a NULL check after of_reserved_mem_lookup() and return -ENODEV if the lookup fails, which is consistent with the existing error handling for of_parse_phandle() failure in the same code block. Fixes: 3a1ce9e3d01b ("net: airoha: Add the capability to allocate hwfd buffers via reserved-memory") Cc: stable@vger.kernel.org Signed-off-by: ZhaoJinming <zhaojinming@uniontech.com> Acked-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-05Merge tag 'drm-fixes-2026-06-06' of https://gitlab.freedesktop.org/drm/kernelLinus Torvalds
Pull drm fixes from Dave Airlie: "Weekly drm fixes, not contributing to things settling down unfortunately. Lots of driver fixes for various bounds checks, leaks and UAF type things, i915/xe probably the most sane, amdgpu has a mix of fixes all over, then ethosu has lots of small fixes. The problem of fixing thing in private has really hit us with the change handle ioctl, and "Sima was right" and we should have disabled the ioctl, since it was only introduced a couple of kernels ago and failed to upstream it's tests in time. The patch here fixes the problems Sima identified, but disables the ioctl as well, with a list of known problems in it and a request for proper tests to be written and upstreamed. It's a niche user ioctl designed for CRIU with AMD ROCm, so I think it's fine to just disable it. Maybe this week will settle down. core: - disable the gem change handle ioctl for security reasons (plan to fix it on list later with proper test coverage) dumb-buffer: - remove strict limits on buffer geometry amdgpu: - BT.2020 fix for DCE - DC bounds checking fixes - SDMA 7.1 fix - UserQ fixes - SI fix - SMU 13 fixes - SMU 14 fixes - GC 12.1 fix - Userptr fix - GC 10.1 fix - GART fix for non-4K pages amdkfd: - UAF race fix - Fix a potential NULL pointer dereference - GC 11 buffer overflow fix for SDMA xe: - Revert removing support for unpublished NVL-S GuC - Suspend fixes related to multi-queue i915: - Fix color blob reference handling in intel_plane_state - Revert "drm/i915/backlight: Remove try_vesa_interface" ethosu: - reject unsupported NPU_OP_RESIZE - fix index of IFM region - fix weight index - fix overflows in DMA-size calculations - reject DMA commands with uninitialized length - fix OOB write in ethosu_gem_cmdstream_copy_and_validate imx: - fix kernel-doc warnings ivpu: - add overflow checks in firmware handling and get_info_ioctl v3d: - wait for pending L2T flush before cleaning caches - fix leak of vaddr - skip CSD when it has zeroed workgroups - fix ref counting in performance monitoring" * tag 'drm-fixes-2026-06-06' of https://gitlab.freedesktop.org/drm/kernel: (50 commits) drm/gem: Try to fix change_handle ioctl, attempt 4 Revert "drm/i915/backlight: Remove try_vesa_interface" accel/ethosu: fix OOB write in ethosu_gem_cmdstream_copy_and_validate() accel/ethosu: reject DMA commands with uninitialized length accel/ethosu: fix arithmetic issues in dma_length() accel/ethosu: fix wrong weight index in NPU_SET_SCALE1_LENGTH on U85 accel/ethosu: reject NPU_OP_RESIZE commands from userspace accel/ethosu: fix IFM region index out-of-bounds in command stream parser drm/v3d: Fix global performance monitor reference counting drm/xe/multi_queue: skip submit when primary queue is suspended drm/xe: Clear pending_disable before signaling suspend fence Revert "drm/xe: Skip exec queue schedule toggle if queue is idle during suspend" drm/amd/pm: smu_v14_0_0: use SoftMin for gfxclk in set_soft_freq_limited_range drm/amdgpu: Fix incorrect VRAM GART mappings on non-4K page size systems drm/amdgpu/userq: move wptr_obj cleanup in mqd_destroy drm/amdgpu: improve the userq seq BO free bit lookup drm/amdgpu/userq: remove the vital queue unmap logging drm/amdkfd: Fix buffer overflow in SDMA queue checkpoint/restore on GFX11 drm/amdkfd: fix NULL dereference in get_queue_ids() drm/amdgpu: set noretry=1 as default for GFX 10.1.x (Navi10/12/14) ...
2026-06-05net: cpsw_new: unregister devlink on port registration failureGuangshuo Li
cpsw_probe() registers devlink before registering the CPSW ports. If cpsw_register_ports() fails, the error path only unregisters the notifiers and then releases the lower level resources. It does not undo the successful cpsw_register_devlink() call, leaving the devlink instance and its parameters registered after probe has failed. Add a devlink cleanup label for the path where devlink registration has already succeeded, and use it when port registration fails. Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Reviewed-by: Alexander Sverdlin <alexander.sverdlin@siemens.com> Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com> Link: https://patch.msgid.link/20260604043115.1409134-1-lgs201920130244@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-05idpf: fix mailbox capability for set device clock timeAlok Tiwari
The current code incorrectly uses VIRTCHNL2_CAP_PTP_SET_DEVICE_CLK_TIME for both direct and mailbox capabilities, causing mailbox-only support to be ignored and potentially reporting IDPF_PTP_NONE. Fixes: d5dba8f7206da ("idpf: add PTP clock configuration") Signed-off-by: Alok Tiwari <alok.a.tiwari@oracle.com> Tested-by: Samuel Salin <Samuel.salin@intel.com> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Link: https://patch.msgid.link/20260602225513.393338-4-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-05ice: fix missing priority callbacks for U.FL DPLL pinsPetr Oros
The U.FL2 input pin advertises DPLL_PIN_CAPABILITIES_PRIORITY_CAN_CHANGE in its capability mask, but ice_dpll_pin_ufl_ops does not provide .prio_get and .prio_set callbacks. As a result the DPLL subsystem cannot report or accept priority for U.FL pins: pin-get omits the prio field on U.FL2 and pin-set with prio is rejected as invalid, even though the capability is present. This prevents user space from using priority to select or disable U.FL2 as a DPLL input source. Reproducer with iproute2 (dpll command): # dpll pin show board-label U.FL2 pin id 16: module-name ice board-label U.FL2 type ext capabilities priority-can-change|state-can-change parent-device: id 0 direction input state selectable phase-offset 0 /* note: no "prio" between "direction" and "state", even though priority-can-change is advertised */ # dpll pin set id 16 parent-device 0 prio 5 RTNETLINK answers: Operation not supported After the fix the prio field is reported by pin show and pin set with prio is accepted on U.FL2. Add the missing .prio_get and .prio_set callbacks to ice_dpll_pin_ufl_ops, reusing ice_dpll_sw_input_prio_{get,set}. The same ops struct is shared by U.FL1 and U.FL2: U.FL2 (input) delegates to the backing hardware input pin, while U.FL1 (output) does not advertise DPLL_PIN_CAPABILITIES_PRIORITY_CAN_CHANGE so the dpll core capability gate never invokes prio_set for it, and prio_get reports the OUTPUT sentinel (ICE_DPLL_PIN_PRIO_OUTPUT) on the output side exactly like the SMA path does today. Fixes: 2dd5d03c77e2 ("ice: redesign dpll sma/u.fl pins control") Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de> Signed-off-by: Petr Oros <poros@redhat.com> Tested-by: Rinitha S <sx.rinitha@intel.com> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Link: https://patch.msgid.link/20260602225513.393338-3-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-06drm/gem: Try to fix change_handle ioctl, attempt 4Simona Vetter
[airlied: just added some comments on how to reenable] On-list because the cat is out of the bag and we're clearly not good enough to figure this out in private. The story thus far: 5e28b7b94408 ("drm: Set old handle to NULL before prime swap in change_handle") tried to fix a race condition between the gem_close and gem_change_handle ioctls, but got a few things wrong: - There's a confusion with the local variable handle, which is actually the new handle, and so the two-stage trick was actually applied to the wrong idr slot. 7164d78559b0 ("drm/gem: fix race between change_handle and handle_delete") tried to fix that by adding yet another code block, but forgot to add the error handling. Which meant we now have two paths, both kinda wrong. - dc366607c41c ("drm: Replace old pointer to new idr") tried to apply another fix, but inconsistently, again because of the handle confusion - this would be the right fix (kinda, somewhat, it's a mess) if we'd do the two-stage approach for the new handle. Except that wasn't the intent of the original fix. We also didn't have an igt merged for the original ioctl, which is a big no-go. This was attempted to address off-list in the original bugfix, and amd QA people claimed the bug was fixed now. Very clearly that's not the case. Here's my attempt to sort this out: - Rename the local variable to new_handle, the old aliasing with args->handle is just too dangerously confusing. - Merge the gem obj lookup with the two-stage idr_replace so that we avoid getting ourselves confused there. - This means we don't have a surplus temporary reference anymore, only an inherited from the idr. A concurrent gem_close on the new_handle could steal that. Fix that with the same two-stage approach create_tail uses. This is a bit overkill as documented in the comment, but I also don't trust my ability to understand this all correctly, so go with the established pattern we have from other ioctls instead for maximum paranoia. - Adjust error paths. I've tried to make the error and success paths common, because they are identical except for which handle is removed and on which we call idr_replace to (re)install the object again. But that made things messier to read, so I've left it at the more verbose version, which unfortunately hides the symmetry in the entire code flow a bit. - While at it, also replace the 7 space indent with 1 tab. And finally, because I flat out don't trust my abilities here at all anymore: - Disable the ioctl until we have the igt situation and everything else sorted out on-list and with full consensus. v2: Sashiko noticed that I didn't handle the error path for idr_replace correctly, it must be checked with IS_ERR_OR_NULL like in gem_handle_delete. So yeah, definitely should just the existing paths 1:1 because this is endless amounts of tricky. Also add the Fixes: line for the original ioctl, I forgot that too. Reported-by: DARKNAVY (@DarkNavyOrg) <vr@darknavy.com> Signed-off-by: Simona Vetter <simona.vetter@ffwll.ch> Fixes: dc366607c41c ("drm: Replace old pointer to new idr") Cc: syzbot+d7c9eed171647e421013@syzkaller.appspotmail.com Cc: stable@vger.kernel.org Cc: Edward Adam Davis <eadavis@qq.com> Cc: Dave Airlie <airlied@redhat.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Fixes: 5e28b7b94408 ("drm: Set old handle to NULL before prime swap in change_handle") Cc: David Francis <David.Francis@amd.com> Cc: Puttimet Thammasaeng <pwn8official@gmail.com> Cc: Christian Koenig <Christian.Koenig@amd.com> Fixes: 7164d78559b0 ("drm/gem: fix race between change_handle and handle_delete") Cc: Zhenghang Xiao <kipreyyy@gmail.com> Fixes: 5e28b7b94408 ("drm: Set old handle to NULL before prime swap in change_handle") Reviewed-by: David Francis <David.Francis@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://patch.msgid.link/20260604194437.1725314-1-simona.vetter@ffwll.ch
2026-06-06Merge tag 'drm-intel-fixes-2026-06-05' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/i915/kernel into drm-fixes - Fix color blob reference handling in intel_plane_state (Chaitanya Kumar Borah) - Revert "drm/i915/backlight: Remove try_vesa_interface" [backlight] (Suraj Kandpal) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Tvrtko Ursulin <tursulin@igalia.com> Link: https://patch.msgid.link/aiKgmwz7VGOaFXIv@linux
2026-06-06Merge tag 'drm-misc-fixes-2026-06-05' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes Short summary of fixes pull: dumb-buffer: - remove strict limits on buffer geometry ethosu: - reject unsupported NPU_OP_RESIZE - fix index of IFM region - fix weight index - fix overflows in DMA-size calculations - reject DMA commands with uninitialized length - fix OOB write in ethosu_gem_cmdstream_copy_and_validate imx: - fix kernel-doc warnings ivpu: - add overflow checks in firmware handling and get_info_ioctl v3d: - wait for pending L2T flush before cleaning caches - fix leak of vaddr - skip CSD when it has zeroed workgroups - fix ref counting in performance monitoring Signed-off-by: Dave Airlie <airlied@redhat.com> From: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260605072602.GA268798@linux.fritz.box
2026-06-05power: supply: max17042_battery: Use modern PM ops to clear up warningNathan Chancellor
When building for a platform that does not have power management, such as s390, there is an unused function warning, as max17042_suspend_soc_alerts() is only used in max17042_suspend(), which is under a CONFIG_PM_SLEEP #ifdef. drivers/power/supply/max17042_battery.c:957:13: error: 'max17042_suspend_soc_alerts' defined but not used [-Werror=unused-function] 957 | static void max17042_suspend_soc_alerts(struct max17042_chip *chip) | ^~~~~~~~~~~~~~~~~~~~~~~~~~~ Use the modern DEFINE_SIMPLE_DEV_PM_OPS(), which allows the compiler to see the functions as used while allowing it to eliminate them as unused during the optimization phase. Use pm_ptr() to allow the compiler to drop max17042_pm_ops when there is no PM support. Fixes: 601885ffb5e9 ("power: supply: max17042_battery: Keep only critical alerts during suspend") Signed-off-by: Nathan Chancellor <nathan@kernel.org> Link: https://patch.msgid.link/20260604-max17042_battery-fix-unused-suspend_soc_alerts-v1-1-3562a68e6f36@kernel.org Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2026-06-05RDMA/siw: Fix endpoint/socket association handlingBernard Metzler
Disassociating a socket from an endpoint via siw_socket_disassoc() may release the last reference on that endpoint and free it. Therefore, don't clear the endpoints socket pointer after calling that function, but within. This fixes a: BUG: KASAN: slab-use-after-free in siw_cm_work_handler (drivers/infiniband/sw/siw/siw_cm.c:1053 drivers/infiniband/sw/siw/siw_cm.c:1075) which occurred after processing a malformed MPA request during connection establishment, causing the new endpoint to be closed. Fixes: 6c52fdc244b5c ("rdma/siw: connection management") Link: https://patch.msgid.link/r/20260604160808.30948-1-bernard.metzler@linux.dev Reported-by: Shuangpeng Bai <shuangpeng.kernel@gmail.com> Signed-off-by: Bernard Metzler <bernard.metzler@linux.dev> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2026-06-05RDMA/irdma: Initialize iwmr->access during MR registrationJacob Moroni
Initialize iwmr->access during initial user mem registration so that it contains a valid value during a subsequent rereg_mr. Otherwise, a rereg_mr that doesn't set IB_MR_REREG_ACCESS (for example, one that only changes the PD) ends up clearing the access flags in HW since iwmr->access is zero-initialized, which is not intended. Fixes: 5ac388db27c4 ("RDMA/irdma: Add support to re-register a memory region") Link: https://patch.msgid.link/r/20260604154104.4035581-1-jmoroni@google.com Signed-off-by: Jacob Moroni <jmoroni@google.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2026-06-05RDMA/irdma: Fix OOB read during CQ MR registrationJacob Moroni
Sashiko pointed out an unrelated bug during a previous patch: https://sashiko.dev/#/patchset/20260512183852.614045-1-jmoroni%40google.com This change fixes the bug by eliminating the cqmr->split field which was not being set properly and instead just checks the CQ resize feature flag directly. The cqmr->split field essentially tracks whether IRDMA_FEATURE_CQ_RESIZE is set, but it was not being set until CQ creation time, which is _after_ CQ memory registration (the only other place where it is referenced). As a result, it would always be false during MR registration and would therefore cause irdma_handle_q_mem to populate cqmr->shadow even for GEN_2 HW and beyond: cqmr->shadow = (dma_addr_t)arr[req->cq_pages]; The issue is that for GEN_2 and beyond, req->cq_pages may be exactly equal to iwmr->page_cnt and therefore equal to the size of arr, which would cause an OOB read by one. Fixes: b48c24c2d710 ("RDMA/irdma: Implement device supported verb APIs") Link: https://patch.msgid.link/r/20260602214423.1315105-2-jmoroni@google.com Signed-off-by: Jacob Moroni <jmoroni@google.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2026-06-05RDMA/irdma: Remove redundant legacy_mode checksJacob Moroni
The driver has the following invariants: 1. legacy_mode is only allowed on GEN_1 hardware (enforced in irdma_alloc_ucontext). 2. GEN_1 hardware does not set IRDMA_FEATURE_CQ_RESIZE or IRDMA_FEATURE_RTS_AE. These feature flags are only set for GEN_2 and GEN_3 hardware. Therefore, legacy_mode is always false if IRDMA_FEATURE_CQ_RESIZE or IRDMA_FEATURE_RTS_AE is set, so remove the redundant checks. Link: https://patch.msgid.link/r/20260602214423.1315105-1-jmoroni@google.com Signed-off-by: Jacob Moroni <jmoroni@google.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2026-06-05RDMA/siw: bound Read Response placement to the RREAD lengthMichael Bommarito
In drivers/infiniband/sw/siw/siw_qp_rx.c, siw_proc_rresp() places each inbound Read Response DDP segment at sge->laddr + wqe->processed and then accumulates wqe->processed, but it never checks the running total against the sink buffer length on continuation segments. siw_check_sge() resolves and validates the sink memory only on the first fragment (the if (!*mem) branch), and siw_rresp_check_ntoh() compares the cumulative length against wqe->bytes only on the final segment (the !frx->more_ddp_segs guard). A connected siw peer that answers an outstanding RREAD with Read Response segments that keep the DDP Last flag clear, carrying more total payload than the RREAD requested, drives wqe->processed past the validated sink buffer; the next siw_rx_data() call writes out of bounds at sge->laddr + wqe->processed. siw runs iWARP over ordinary routable TCP, so the peer is the remote end of an established RDMA connection and needs no local privilege. Bound every segment before placement, exactly as siw_proc_send() and siw_proc_write() already do for their tagged and untagged paths, and terminate the connection with a base-or-bounds DDP error when the Read Response would overrun the sink buffer. This is the second receive-path length fix for this file. A separate change rejects an MPA FPDU length that underflows the per-fragment remainder in the header decode; that guard does not cover this case, because here each individual segment length is self-consistent and only the accumulated placement offset overruns the buffer. Fixes: 8b6a361b8c48 ("rdma/siw: receive path") Link: https://patch.msgid.link/r/20260602194700.2273758-1-michael.bommarito@gmail.com Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2026-06-05vfio: prevent infinite loop in vfio_mig_get_next_state() on blocked arcJunrui Luo
vfio_mig_get_next_state() walks vfio_from_fsm_table[] one step at a time, looping to skip optional states the device does not support until *next_fsm is supported. A blocked transition is encoded as VFIO_DEVICE_STATE_ERROR, which the trailing return reports as -EINVAL. The skip loop does not account for the ERROR sentinel. state_flags_table[ERROR] is ~0U and vfio_from_fsm_table[ERROR][*] is ERROR, so once *next_fsm becomes ERROR the loop condition stays true and *next_fsm never changes. The blocked arcs STOP_COPY -> PRE_COPY and STOP_COPY -> PRE_COPY_P2P map to ERROR yet pass the support check on a precopy-capable device, causing the loop to spin forever while holding the driver state mutex. This can result in a soft lockup, and a panic with softlockup_panic set. Terminate the skip loop on the ERROR sentinel so a blocked transition falls through to the existing return and reports -EINVAL. Fixes: 4db52602a607 ("vfio: Extend the device migration protocol with PRE_COPY") Reported-by: Yuhao Jiang <danisjiang@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: Junrui Luo <moonafterrain@outlook.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Link: https://lore.kernel.org/r/SYBPR01MB7881290BBDE79B61AE6A017FAF122@SYBPR01MB7881.ausprd01.prod.outlook.com Signed-off-by: Alex Williamson <alex@shazbot.org>
2026-06-05vfio/nvgrace-gpu: Add Blackwell-Next GPU readiness check via CXL DVSECAnkit Agrawal
Add a CXL DVSEC-based readiness check for Blackwell-Next GPUs alongside the existing legacy BAR0 polling path. The CXL Device DVSEC offset is discovered at probe time. Probe, fault and read/write paths then branch on that to use either the legacy BAR0 polling or the CXL DVSEC polling. The CXL path polls Memory_Active, requiring MEM_INFO_VALID within 1s and MEM_ACTIVE within Memory_Active_Timeout (up to 256s) as per CXL spec r4.0 sec 8.1.3.8.2. Given the long worst-case wait, the CXL poll runs outside memory_lock with only a quick readiness check is done under the lock. The poll loops sleep with schedule_timeout_killable() and return -EINTR on a fatal signal. This avoids hung-task panics during the long uninterruptible wait. Extend this to the legacy based wait as well for improvement. In the fault handler the wait runs locklessly before memory_lock. If a reset races in, the in-lock recheck returns -EAGAIN and the wait is retried rather than returning a spurious VM_FAULT_SIGBUS. Add PCI_DVSEC_CXL_MEM_ACTIVE_TIMEOUT to pci_regs.h for the timeout field. Cc: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Cc: Kevin Tian <kevin.tian@intel.com> Suggested-by: Alex Williamson <alex@shazbot.org> Signed-off-by: Ankit Agrawal <ankita@nvidia.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Link: https://lore.kernel.org/r/20260602063015.3915-1-ankita@nvidia.com Signed-off-by: Alex Williamson <alex@shazbot.org>
2026-06-05RDMA/mlx5: Fix state and counter desync on loopback enable failureLi RongQing
In mlx5_ib_enable_lb(), dev->lb.enabled was unconditionally set to true even if mlx5_nic_vport_update_local_lb() failed. Fix this by only setting dev->lb.enabled on success. On failure, roll back the reference counters and return the error. Link: https://patch.msgid.link/r/20260601095818.2227-1-lirongqing@baidu.com Signed-off-by: Li RongQing <lirongqing@baidu.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2026-06-05RDMA/mlx5: Fix error propagation in __mlx5_ib_addLi RongQing
__mlx5_ib_add() currently returns -ENOMEM on any stage initialization failure, losing the actual error code returned by the init function. This makes it impossible for callers to distinguish between different failure reasons (e.g. -EINVAL, -EIO, -EOPNOTSUPP) and leads to misleading error handling. Fix it by returning the actual error code stored in 'err'. Link: https://patch.msgid.link/r/20260601095654.2178-1-lirongqing@baidu.com Signed-off-by: Li RongQing <lirongqing@baidu.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2026-06-05accel/amdxdna: Require carveout when PASID and force_iova are disabledLizhi Hou
When both PASID and force_iova are disabled, carveout memory should be used. Reject buffer allocations that cannot use carveout memory in this configuration and return an error. Fixes: 3cc5d7a59519 ("accel/amdxdna: Add carveout memory support for non-IOMMU systems") Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> Signed-off-by: Lizhi Hou <lizhi.hou@amd.com> Link: https://patch.msgid.link/20260604195459.2423279-1-lizhi.hou@amd.com
2026-06-05IB/cm: Fix av cm device leak on an error path in cm_init_av_by_path()Jason Gunthorpe
Codex pointed out that cm_init_av_by_path() can call cm_set_av_port() which takes a reference on the cm device, but then can immediately return error if ib_init_ah_attr_from_path() fails. Since callers like ib_send_cm_req() put the av on the stack this leaks that cm device reference. Re-order cm_init_av_by_path() so it doesn't touch the av until it has done all its failable work, and then update the av in one shot so it is either left alone or fully init'd. Sashiko also pointed out that the cm_destroy_av() prior to cm_init_av_by_path() is harmful as it leaves the AV broken in the error case and thus the REJ won't send. Since cm_init_av_by_path() is now atomic it is safe to delete the cm_destroy_av(). On succees the av from cm_init_av_for_response() is cleaned up by cm_init_av_by_path(), on failure the 'goto rejected' guarentees the av is destroyed during ib_destroy_cm_id(). Fixes: 76039ac9095f ("IB/cm: Protect cm_dev, cm_ports and mad_agent with kref and lock") Link: https://patch.msgid.link/r/0-v1-38292501f539+14f-ib_cm_av_leak_jgg@nvidia.com Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2026-06-05RDMA/bnxt_re: Update create_qp to use QP buffer umem attrsSriharsha Basavapatna
Use ib_umem_get_attr_or_va() helper to pin QP buffer umems. Pass attribute ids SQ_BUF_UMEM and RQ_BUF_UMEM for respective buffers. Link: https://patch.msgid.link/r/20260602145618.21643-1-sriharsha.basavapatna@broadcom.com Signed-off-by: Sriharsha Basavapatna <sriharsha.basavapatna@broadcom.com> Reviewed-by: Selvin Xavier <selvin.xavier@broadcom.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2026-06-05RDMA/hfi1: Open-code rvt_set_ibdev_name()Arnd Bergmann
clang warns about a function missing a printf attribute: include/rdma/rdma_vt.h:457:47: error: diagnostic behavior may be improved by adding the 'format(printf, 2, 3)' attribute to the declaration of 'rvt_set_ibdev_name' [-Werror,-Wmissing-format-attribute] 447 | static inline void rvt_set_ibdev_name(struct rvt_dev_info *rdi, | __attribute__((format(printf, 2, 3))) 448 | const char *fmt, const char *name, 449 | const int unit) The helper was originally added as an abstraction for the hfi1 and qib drivers needing the same thing, but now qib is gone, and hfi1 is the only remaining user of rdma_vt. Avoid the warning and allow the compiler to check the format string by open-coding the helper and directly assigning the device name. Fixes: 5084c8ff21f2 ("IB/{rdmavt, hfi1, qib}: Self determine driver name") Link: https://patch.msgid.link/r/20260602140453.3542427-1-arnd@kernel.org Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Kees Cook <kees@kernel.org> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2026-06-05RDMA/umem: Be careful about boundary conditions in ib_umem_find_best_pgsz()Jason Gunthorpe
Several corner cases, especially important on 32 bits: - umem->iova is u64, the function argument should pass in u64 or iova will be truncated - Check that the length is not too large for the iova - Check that lengths > 4G don't overflow the GENMASK Link: https://patch.msgid.link/r/2-v1-88303e9e509f+f7-ib_umem_types_jgg@nvidia.com Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2026-06-05misc: fastrpc: fix use-after-free race in fastrpc_map_createZhenghang Xiao
fastrpc_map_lookup returns a raw pointer after releasing fl->lock. The caller fastrpc_map_create then calls fastrpc_map_get (kref_get_unless_zero) on this unprotected pointer. A concurrent MEM_UNMAP can free the map between the lock release and the kref operation, resulting in a use-after-free on the freed slab object. Restore the take_ref parameter to fastrpc_map_lookup so the reference is acquired atomically under fl->lock before the pointer is exposed to the caller. Fixes: 10df039834f8 ("misc: fastrpc: Skip reference for DMA handles") Cc: stable@vger.kernel.org Signed-off-by: Zhenghang Xiao <kipreyyy@gmail.com> Signed-off-by: Srinivas Kandagatla <srini@kernel.org> Link: https://patch.msgid.link/20260530204528.116920-5-srini@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-06-05misc: fastrpc: Fix NULL pointer dereference in rpmsg callbackMukesh Ojha
A NULL pointer dereference was observed on Hawi at boot when the DSP sends a glink message before fastrpc_rpmsg_probe() has completed initialization: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000178 pc : _raw_spin_lock_irqsave+0x34/0x8c lr : fastrpc_rpmsg_callback+0x3c/0xcc [fastrpc] ... Call trace: _raw_spin_lock_irqsave+0x34/0x8c (P) fastrpc_rpmsg_callback+0x3c/0xcc [fastrpc] qcom_glink_native_rx+0x538/0x6a4 qcom_glink_smem_intr+0x14/0x24 [qcom_glink_smem] The faulting address 0x178 corresponds to the lock variable inside struct fastrpc_channel_ctx, confirming that cctx is NULL when fastrpc_rpmsg_callback() attempts to take the spinlock. There are two issues here. First, dev_set_drvdata() is called before spin_lock_init() and idr_init(), leaving a window where the callback can retrieve a valid cctx pointer but operate on an uninitialized spinlock. Second, the rpmsg channel becomes live as soon as the driver is bound, so fastrpc_rpmsg_callback() can fire before dev_set_drvdata() is called at all, resulting in dev_get_drvdata() returning NULL. Fix both issues by moving all cctx initialization ahead of dev_set_drvdata() so the structure is fully initialized before it becomes visible to the callback, and add a NULL check in fastrpc_rpmsg_callback() as a guard against any remaining window. Fixes: f6f9279f2bf0 ("misc: fastrpc: Add Qualcomm fastrpc basic driver model") Cc: stable@vger.kernel.org Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> Reviewed-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Srinivas Kandagatla <srini@kernel.org> Link: https://patch.msgid.link/20260530204528.116920-4-srini@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-06-05misc: fastrpc: fix DMA address corruption due to find_vma misuseJunrui Luo
fastrpc_get_args() uses find_vma() to look up the VMA for a user-provided pointer and compute a DMA address offset. When the address falls in a gap before the returned VMA, (ptr & PAGE_MASK) - vma->vm_start underflows, corrupting the DMA address sent to the DSP. Replace find_vma() with vma_lookup(), which returns NULL when the address is not contained within any VMA. Cc: stable@vger.kernel.org Fixes: 80f3afd72bd4 ("misc: fastrpc: consider address offset before sending to DSP") Reported-by: Yuhao Jiang <danisjiang@gmail.com> Signed-off-by: Junrui Luo <moonafterrain@outlook.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Srinivas Kandagatla <srini@kernel.org> Link: https://patch.msgid.link/20260530204528.116920-3-srini@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
generated by cgit v1.2.3 (git 2.25.1) at 2026-07-10 15:29:52 +0000