summaryrefslogtreecommitdiff
path: root/drivers/net
AgeCommit message (Collapse)Author
2026-06-30netconsole: do not warn when the best-effort skb allocation failsBreno Leitao
find_skb() allocates the skb with GFP_ATOMIC as a best-effort attempt: on failure it falls back to the preallocated skb pool and, failing that, polls the device and retries. The allocation failing is therefore an expected and fully handled condition, but without __GFP_NOWARN the page allocator still emits a warn_alloc() splat with a full stack trace on every miss, which then consumes the whole SKB pool, that would be useful printing the real issue rather than the memory failure. Pass __GFP_NOWARN so the best-effort allocation stays quiet and lets the existing fallback path do its job. Signed-off-by: Breno Leitao <leitao@debian.org> Link: https://patch.msgid.link/20260629-netpoll_no_warn-v1-1-f380f0b2cd0c@debian.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-30net: sgi: ioc3-eth: fix split TX DMA mapping lengthsXu Rao
When a linear skb crosses a 16 KiB boundary, ioc3_start_xmit() splits it into two buffers of lengths s1 and s2. The descriptor advertises those lengths through B1CNT and B2CNT. The first buffer is mapped with s1, but the second buffer is also mapped with s1 even though the device is told to fetch s2 bytes from it. When the lengths differ, the DMA mapping does not cover the same region as the second descriptor buffer, which can result in incorrect cache maintenance or a DMA fault on implementations that enforce the mapped range. There is a separate mismatch in the error path. If mapping the second buffer fails, only d1 needs to be unmapped. d1 was mapped for s1 bytes, but the driver unmaps it using the full packet length. Streaming DMA mappings must be unmapped with the same size used for the corresponding map operation. Map the second buffer with s2 and unmap the first buffer with s1 when the second mapping fails. Cc: <stable+noautosel@kernel.org> # untested fix for ancient HW Signed-off-by: Xu Rao <raoxu@uniontech.com> Reviewed-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Link: https://patch.msgid.link/4E1486BC4536407E+20260629080623.908426-1-raoxu@uniontech.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-30net: sgi: ioc3-eth: unregister netdev before freeing DMA ringsXu Rao
ioc3eth_remove() frees the coherent RX and TX descriptor rings before unregistering the netdev. If the interface is running, unregister_netdev() invokes ioc3_close() through ndo_stop. ioc3_close() stops the device and then calls ioc3_free_rx_bufs() and ioc3_clean_tx_ring(). Both cleanup functions access descriptors in the rings, so the current ordering causes CPU accesses to freed coherent memory. Until ioc3_stop() disables RX and TX DMA, the device may also continue using the freed ring addresses. Unregister the netdev before releasing the rings. This lets the core close a running interface and quiesce the device while the rings are still valid. Keep the explicit timer deletion because ndo_stop is not called when the interface is already down. Cc: <stable+noautosel@kernel.org> # untested fix for ancient HW Signed-off-by: Xu Rao <raoxu@uniontech.com> Reviewed-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Link: https://patch.msgid.link/40CD736C4911C181+20260629085053.964383-1-raoxu@uniontech.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-30virtio_net: disable cb when NAPI is busy-polledLongjun Tang
When busy-poll is active, napi_schedule_prep() returns false in virtqueue_napi_schedule(), so virtqueue_disable_cb() is skipped. The device may keep firing irqs until reaches virtqueue_napi_complete(). Under load (received == budget), it will lead to a large number of spurious interrupts. Fix it by disabling the callback at the virtnet_poll() entry. This keeps the callback off while we poll and it is re-enabled by virtqueue_napi_complete() when going idle. Fixes: ceef438d613f ("virtio_net: remove custom busy_poll") Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Longjun Tang <tanglongjun@kylinos.cn> Link: https://patch.msgid.link/20260629024230.37325-1-lange_tang@163.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-30bonding: no longer rely on RTNL in bond_fill_info()Eric Dumazet
Add READ_ONCE()/WRITE_ONCE() annotations on port->is_enabled. While this field is written under bond->mode_lock protection, is is read without this lock being held. Change bond_fill_info() to acquire RCU and use READ_ONCE() to read bond->params fields that can be updated concurrently from sysfs/procfs/rtnetlink. Add const qualifiers to bond_uses_primary(), __agg_active_ports(), bond_option_active_slave_get_rcu(), bond_3ad_get_active_agg_info(), __bond_3ad_get_active_agg_info() helpers. Signed-off-by: Eric Dumazet <edumazet@google.com> Cc: Jay Vosburgh <jv@jvosburgh.net> Cc: Andrew Lunn <andrew+netdev@lunn.ch> Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org> Link: https://patch.msgid.link/20260629173200.469953-1-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-30net: replace linux/gpio.h inclusionsArnd Bergmann
linux/gpio.h should no longer be used, change these in drivers/net to linux/gpio/consumer.h where possible, with b53 being the only one still using linux/gpio/legacy.h. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Reviewed-by: Linus Walleij <linusw@kernel.org> Link: https://patch.msgid.link/20260629132633.1300009-7-arnd@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-30sfc: support pio mapping based on cxlAlejandro Lucero
A PIO buffer is a region of device memory to which the driver can write a packet for TX, with the device handling the transmit doorbell without requiring a DMA for getting the packet data, which helps reducing latency in certain exchanges. With CXL mem protocol this latency can be lowered further. With a device supporting CXL and successfully initialised, use the cxl region to map the memory range and use this mapping for PIO buffers. Signed-off-by: Alejandro Lucero <alucerop@amd.com> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Acked-by: Edward Cree <ecree.xilinx@gmail.com> Link: https://patch.msgid.link/20260630151346.31201-6-alejandro.lucero-palau@amd.com Signed-off-by: Dave Jiang <dave.jiang@intel.com>
2026-06-30sfc: obtain and map cxl range using devm_cxl_probe_memAlejandro Lucero
Use core API for safely obtain the CXL range linked to an HDM committed by the BIOS. Map such a range for being used as the ctpio buffer. A potential user space action through sysfs unbinding or core cxl modules remove will trigger sfc driver device detachment, with that case not racing with this mapping as this is done during driver probe and therefore protected with device lock against those user space actions. Signed-off-by: Alejandro Lucero <alucerop@amd.com> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Acked-by: Edward Cree <ecree.xilinx@gmail.com> Signed-off-by: Dan Williams <djbw@kernel.org> Link: https://patch.msgid.link/20260630151346.31201-5-alejandro.lucero-palau@amd.com Signed-off-by: Dave Jiang <dave.jiang@intel.com>
2026-06-30sfc: Initialize cxl dpaAlejandro Lucero
Use cxl_set_capacity() for DPA initialization as no mailbox is available. Signed-off-by: Alejandro Lucero <alucerop@amd.com> Reviewed-by: Dan Williams <dan.j.williams@intel.com> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Reviewed-by: Ben Cheatham <benjamin.cheatham@amd.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Acked-by: Edward Cree <ecree.xilinx@gmail.com> Link: https://patch.msgid.link/20260630151346.31201-4-alejandro.lucero-palau@amd.com Signed-off-by: Dave Jiang <dave.jiang@intel.com>
2026-06-30sfc: Map cxl regsAlejandro Lucero
Use cxl core functions for discovering and mapping CXL device registers. Signed-off-by: Alejandro Lucero <alucerop@amd.com> Reviewed-by: Dan Williams <dan.j.williams@intel.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Reviewed-by: Ben Cheatham <benjamin.cheatham@amd.com> Acked-by: Edward Cree <ecree.xilinx@gmail.com> Link: https://patch.msgid.link/20260630151346.31201-3-alejandro.lucero-palau@amd.com Signed-off-by: Dave Jiang <dave.jiang@intel.com>
2026-06-30sfc: add cxl supportAlejandro Lucero
Add CXL initialization based on new CXL API for accel drivers and make it dependent on kernel CXL configuration. Signed-off-by: Alejandro Lucero <alucerop@amd.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Acked-by: Edward Cree <ecree.xilinx@gmail.com> Reviewed-by: Alison Schofield <alison.schofield@intel.com> Reviewed-by: Dan Williams <dan.j.williams@intel.com> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Link: https://patch.msgid.link/20260630151346.31201-2-alejandro.lucero-palau@amd.com Signed-off-by: Dave Jiang <dave.jiang@intel.com>
2026-06-30wifi: ath12k: correct monitor destination ring sizeAaradhana Sahu
The default memory profile configures rxdma_monitor_dst_ring_size as 8092, which is a typo. The intended value is 8192, consistent with all other ring sizes in the table being powers of two. Correct the monitor destination ring size to 8192. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1 Fixes: defae535dd63 ("wifi: ath12k: Add a table of parameters entries impacting memory consumption") Signed-off-by: Aaradhana Sahu <aaradhana.sahu@oss.qualcomm.com> Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Link: https://patch.msgid.link/20260616062342.4079796-1-aaradhana.sahu@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-06-30wifi: ath12k: change MAC buffer ring size to 4096Yingying Tang
For WCN7850, MAC buffer ring size is updated to 2048 in 955df16f2a4c3 ("wifi: ath12k: change MAC buffer ring size to 2048") to increase peak throughput. But during the RX process, a phenomenon can still be observed where the throughput drops by about 30% from its peak value and then recovers, and this behavior repeats during RX. After increasing MAC buffer ring size to 4096, the data rate drop has gone. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 Signed-off-by: Yingying Tang <yingying.tang@oss.qualcomm.com> Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Link: https://patch.msgid.link/20260610031358.2043716-1-yingying.tang@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-06-30wifi: ath12k: Skip peer link info update in rx_status for monitor MSDUsSushant Butta
Do not populate peer and link_id in ieee80211_rx_status for monitor MSDUs. The monitor RX path is handled differently in mac80211 when RX_FLAG_ONLY_MONITOR is set, and does not consume peer/link metadata. As such, looking up the peer and updating link_id here is unnecessary. Additionally, this metadata is not required for monitor mode delivery, and performing the lookup/update introduces redundant work and the potential for inconsistent rx_status state if multiple paths modify it. Hence, remove the peer lookup and link_id update from the monitor MSDU delivery path. This also removes the per-MSDU debug logging in the monitor path, slightly reducing debuggability, but avoids unnecessary overhead in the monitor RX path. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1 Signed-off-by: Sushant Butta <sushant.butta@oss.qualcomm.com> Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Link: https://patch.msgid.link/20260609064856.547032-3-sushant.butta@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-06-30wifi: ath12k: Skip setting RX_FLAG_8023 for Ethernet-II (DIX) frames in ↵Sushant Butta
monitor mode Monitor mode delivers raw 802.11 frames, not 802.3/Ethernet frames. Setting RX_FLAG_8023 for monitor RX is incorrect and can break userspace capture and analysis. Do not update this flag in the monitor path to ensure correct handling of captured frames. In the monitor path, RX_FLAG_ONLY_MONITOR is always set before decap is evaluated, which forces decap to remain DP_RX_DECAP_TYPE_RAW. As a result, the condition to set RX_FLAG_8023 can never be satisfied. Hence, drop this unreachable code. Also remove the unused hal_rx_mon_ppdu_info parameter from ath12k_dp_mon_rx_deliver_msdu(), as it was passed but never used. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1 Signed-off-by: Sushant Butta <sushant.butta@oss.qualcomm.com> Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Link: https://patch.msgid.link/20260609064856.547032-2-sushant.butta@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-06-30wifi: ath12k: Show per-radio center freq in dp statsSreeramya Soratkal
Currently, the frequency on which each radio is operating is not available in device_dp_stats. This information is helpful in debugging the channel-specific throughput and is available with iw/nl80211 dump. Extend the device_dp_stats dump to display the center frequency in the existing per-radio loop. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1 Signed-off-by: Sreeramya Soratkal <sreeramya.soratkal@oss.qualcomm.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Reviewed-by: Aishwarya R <aishwarya.r@oss.qualcomm.com> Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com> Link: https://patch.msgid.link/20260626085253.3927269-4-sreeramya.soratkal@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-06-30wifi: ath12k: Add timestamp to dp stats displaySreeramya Soratkal
In MLO configurations the device_dp_stats debugfs file is read separately for each ath12k device. Without a timestamp it is impossible to know whether two snapshots were taken at the same moment, making counter comparisons across devices unreliable. Prepend a ktime-based millisecond timestamp to the output header so the reader can confirm when the snapshot was taken. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1 Signed-off-by: Sreeramya Soratkal <sreeramya.soratkal@oss.qualcomm.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Reviewed-by: Aishwarya R <aishwarya.r@oss.qualcomm.com> Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com> Link: https://patch.msgid.link/20260626085253.3927269-3-sreeramya.soratkal@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-06-30wifi: ath12k: Use runtime device count in dp stats displaySreeramya Soratkal
The REO Rx Received and Rx WBM REL SRC Errors display loops in ath12k_debugfs_dump_device_dp_stats() iterate up to the compile-time constant ATH12K_MAX_DEVICES. This unconditionally prints zeros in columns with no hardware behind it, making the output misleading. Replace the compile-time bound with the runtime ab->ag->num_devices so only live device slots appear in the output. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1 Signed-off-by: Sreeramya Soratkal <sreeramya.soratkal@oss.qualcomm.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Reviewed-by: Aishwarya R <aishwarya.r@oss.qualcomm.com> Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com> Link: https://patch.msgid.link/20260626085253.3927269-2-sreeramya.soratkal@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-06-30wifi: ath12k: Advertise multicast Ethernet encapsulation offload supportTamizh Chelvam Raja
Advertise IEEE80211_OFFLOAD_ENCAP_MCAST to inform mac80211 that multicast frame encapsulation is handled in hardware. This allows mac80211 to pass Ethernet-formatted multicast frames directly to the driver. In ath12k_wifi7_mac_op_tx(), refine the logic that selects the MLO multicast replication path. Add a sta pointer check so that only unicast Hardware-encap frames use the direct transmit path, while multicast Hardware-encap frames fall through to the MLO replication loop and are transmitted on each active link. In the MLO replication loop, use skb_clone() for Hardware-encap frames. These frames are already in Ethernet format and do not require 802.11 link address rewriting by ath12k_mlo_mcast_update_tx_link_address(). Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1 Signed-off-by: Tamizh Chelvam Raja <tamizh.raja@oss.qualcomm.com> Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Link: https://patch.msgid.link/20260623100501.2100119-1-tamizh.raja@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-06-30wifi: ath12k: advertise ieee_link_id in vdev start MLO paramsManish Dharanenthiran
Firmware builds the AP MLD partner profile from the hw_link_id passed in the vdev start parameters. However, hw_link_id is not always the same as the logical per-MLD ieee_link_id, since ieee_link_id is assigned per MLD and not per pdev. This matters in mixed MLO and SLO setups. For example: MLD 1 - 5 GHz + 6 GHz (2-link MLO): ieee_link_id 0 and 1 MLD 2 - 6 GHz only (1-link SLO): ieee_link_id 0 MLD 3 - 5 GHz only (1-link SLO): ieee_link_id 0 The same physical 6 GHz radio can use ieee_link_id 1 for one MLD and ieee_link_id 0 for another. Pass the correct ieee_link_id to firmware so it can build accurate per-STA profile elements. Add ieee_link_id to wmi_vdev_start_mlo_params for the self link and to wmi_partner_link_info for each partner link. Populate these fields in ath12k_mac_mlo_get_vdev_args() from the corresponding vdev link_id before encoding the WMI command. Introduce two new flags in ML params to indicate to firmware when the new fields are valid: ATH12K_WMI_FLAG_MLO_IEEE_LINK_IDX_VALID BIT(18) for the self link ATH12K_WMI_FLAG_MLO_IEEE_LINK_IDX_VALID_PARTNER BIT(19) for partner links Firmware parses ieee_link_id only when the matching flag is set. Also fix the debug message by using correct format specifiers and host-endian values instead of __le32 values. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1 Co-developed-by: Hari Naraayana Desikan Kannan <hari.kannan@oss.qualcomm.com> Signed-off-by: Hari Naraayana Desikan Kannan <hari.kannan@oss.qualcomm.com> Co-developed-by: Karthik M <karthik.m@oss.qualcomm.com> Signed-off-by: Karthik M <karthik.m@oss.qualcomm.com> Signed-off-by: Manish Dharanenthiran <manish.dharanenthiran@oss.qualcomm.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com> Link: https://patch.msgid.link/20260623-ieee_link_id-v2-1-8a89d71baf58@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-06-30wifi: ath12k: reset REOQ LUT addresses before firmware stopAishwarya R
During module removal, REOQ LUT cleanup writes 0 to the REOQ/ML-REOQ LUT address registers. That cleanup runs from ath12k_core_stop(), after ath12k_qmi_firmware_stop() has already stopped the firmware (mode OFF), so the register writes can hit an invalid target access. Move the REOQ LUT register reset before ath12k_qmi_firmware_stop(), so the registers are cleared before stopping the firmware, while register access is still valid. Additionally, handle the error path where firmware-ready setup fails after LUT programming but before core_stop() is reached, ensuring the registers are properly reset in that case as well. On the crash-recovery path, ath12k_core_reconfigure_on_crash() calls ath12k_core_qmi_firmware_ready(), which re-enters ath12k_dp_setup() and ath12k_dp_reoq_lut_setup(), so the LUT registers are reprogrammed before use and stale values do not persist across recovery. There is a brief window between the crash and when the LUT registers are reprogrammed during recovery, during which the registers still hold the freed DMA memory addresses. This is safe because the device is non-functional in that window and will not initiate any DMA access until firmware is restarted and the registers are reprogrammed. No functional issue has been observed so far due to this sequence. However, this change proactively avoids potential issues such as invalid register accesses after firmware stop during module removal and error handling. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1 Co-developed-by: P Praneesh <praneesh.p@oss.qualcomm.com> Signed-off-by: P Praneesh <praneesh.p@oss.qualcomm.com> Signed-off-by: Aishwarya R <aishwarya.r@oss.qualcomm.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Reviewed-by: Tamizh Chelvam Raja <tamizh.raja@oss.qualcomm.com> Link: https://patch.msgid.link/20260619120751.363340-1-aishwarya.r@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-06-30wifi: ath12k: expand UserPD ID mask to support up to 8 PDsAaradhana Sahu
Currently ATH12K_USERPD_ID_MASK uses GENMASK(9, 8), which defines a 2-bit field and limits supported UserPD IDs to values 0-3. Future IPQ5332 multi-PD platform variants support more than three UserPDs. Expand ATH12K_USERPD_ID_MASK to GENMASK(10, 8), increasing the field width to 3 bits and allowing UserPD IDs from 0-7. ATH12K_USERPD_ID_MASK is currently used only while constructing the ath12k AHB PAS ID, so this change does not affect existing platforms. Also remove the unused ATH12K_MAX_UPDS definition. Tested-on: IPQ5332 hw1.0 AHB WLAN.WBE.1.6-01275-QCAHKSWPL_SILICONZ-1 Signed-off-by: Aaradhana Sahu <aaradhana.sahu@oss.qualcomm.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com> Link: https://patch.msgid.link/20260604031551.4178754-1-aaradhana.sahu@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-06-30wifi: ath12k: tighten RX monitor TLV bounds checkMiaoqing Pan
Validate the pointer to the next RX monitor TLV more strictly by ensuring that at least a full TLV header is available within the status buffer before continuing TLV parsing. Prevent potential out-of-bounds access when handling malformed or truncated RX monitor status data. Tested-on: QCC2072 hw1.0 PCI WLAN.COL.1.0.c2-00068-QCACOLSWPL_V1_TO_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 Signed-off-by: Miaoqing Pan <miaoqing.pan@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Link: https://patch.msgid.link/20260509025819.1641630-6-miaoqing.pan@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-06-30wifi: ath12k: add dp_mon support 32-bit TLV headersMiaoqing Pan
Wi-Fi 7 monitor status parsing in dp_mon currently assumes a 64-bit TLV header and directly decodes tag/len/userid from struct hal_tlv_64_hdr. On chips using a 32-bit TLV header (e.g. QCC2072), this causes monitor RX status packets to be dropped during TLV parsing. Introduce HAL helpers to decode TLV header fields (tag/len/userid/value) for both 32-bit and 64-bit header layouts. Without changing the actual TLV parsing logic. Tested-on: QCC2072 hw1.0 PCI WLAN.COL.1.0.c2-00068-QCACOLSWPL_V1_TO_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 Signed-off-by: Miaoqing Pan <miaoqing.pan@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Link: https://patch.msgid.link/20260509025819.1641630-5-miaoqing.pan@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-06-30wifi: ath12k: add HAL ops for monitor TLV header decode and alignmentMiaoqing Pan
Wi-Fi 7 monitor RX status TLV parsing needs to decode TLV headers and advance the pointer with the correct header alignment. Different targets use different TLV header layouts (32-bit vs 64-bit), but the HAL ops for dp_mon RX status header decode and header alignment were not populated for all wifi7 targets. Add dp_mon RX status TLV header decode callbacks and TLV header alignment helpers to the wifi7 HAL ops for QCC2072, QCN9274 and WCN7850. Export helpers to query the required TLV header alignment for 32-bit and 64-bit TLV headers so the caller can align the TLV walk correctly across targets. Tested-on: QCC2072 hw1.0 PCI WLAN.COL.1.0.c2-00068-QCACOLSWPL_V1_TO_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 Signed-off-by: Miaoqing Pan <miaoqing.pan@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Link: https://patch.msgid.link/20260509025819.1641630-4-miaoqing.pan@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-06-30wifi: ath12k: refactor HAL TLV32/64 decode helpersMiaoqing Pan
Change TLV decode helpers to return the TLV value pointer and optionally decode tag/len/usrid via out parameters. This allows reusing the helpers for DP monitor RX status header TLV parsing and avoids duplicated header decoding in callers. No functional change intended. Tested-on: QCC2072 hw1.0 PCI WLAN.COL.1.0.c2-00068-QCACOLSWPL_V1_TO_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 Signed-off-by: Miaoqing Pan <miaoqing.pan@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Link: https://patch.msgid.link/20260509025819.1641630-3-miaoqing.pan@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-06-30wifi: ath12k: fix TLV32 length maskMiaoqing Pan
HAL_TLV_HDR_LEN was using the wrong bitmask; fix it to cover bits [21:10]. Also drop HAL_SRNG_TLV_HDR_{TAG,LEN} and use the generic TLV header bit definitions for TLV32/TLV64 encode/decode to avoid redundant macros. Tested-on: QCC2072 hw1.0 PCI WLAN.COL.1.0.c2-00068-QCACOLSWPL_V1_TO_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices") Signed-off-by: Miaoqing Pan <miaoqing.pan@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Link: https://patch.msgid.link/20260509025819.1641630-2-miaoqing.pan@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-06-30wifi: ath12k: avoid setting 320MHz support on non 6GHz bandNicolas Escande
On a split phy qcn9274 (2.4GHz + 5GHz low), "iw phy" reports 320MHz related features on the 5GHz band while it should not: Wiphy phy1 [...] Band 2: [...] EHT Iftypes: managed [...] EHT PHY Capabilities: (0xe2ffdbe018778000): 320MHz in 6GHz Supported [...] Beamformee SS (320MHz): 7 [...] Number Of Sounding Dimensions (320MHz): 3 [...] EHT MCS/NSS: (0x22222222222222222200000000): This is also reflected in the beacons sent by a mesh interface started on that band. They erroneously advertise 320MHz support too. This should not happen as IEEE Std 802.11-2024, subclause 9.4.2.323.3 says we should not set the 320MHz related fields when not operating on a 6GHz band. For example it says about Bit 0 "Support For 320 MHz In 6 GHz" "Reserved if the EHT Capabilities element is indicating capabilities for the 2.4 GHz or 5 GHz bands." Fix this by clearing the related bits when converting from WMI eht phy capabilities to mac80211 phy capabilities, for bands other than 6GHz. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00218-QCAHKSWPL_SILICONZ-1 Signed-off-by: Nicolas Escande <nico.escande@gmail.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com> Link: https://patch.msgid.link/20260623151613.72113-1-nico.escande@gmail.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-06-30wifi: ath12k: remove unused QMI definitionsAaradhana Sahu
The driver contains several unused QMI definitions such as response length macros, message IDs, firmware segment length definitions, and CALDB address size definitions. Remove these unused definitions as they are not referenced anywhere in the driver. No functional change intended. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1 Signed-off-by: Aaradhana Sahu <aaradhana.sahu@oss.qualcomm.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Link: https://patch.msgid.link/20260623035104.3765404-1-aaradhana.sahu@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-06-30wifi: ath12k: use %u for unsigned variables in QMI debug logsRaj Kumar Bhagat
Replace incorrect %d format specifiers with %u for unsigned variables in qmi.c debug messages. Also add missing trailing '\n' in log messages to ensure proper termination. No functional change intended. Tested-on: Compile tested only. Signed-off-by: Raj Kumar Bhagat <raj.bhagat@oss.qualcomm.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com> Link: https://patch.msgid.link/20260623-qmi-debug-log-v1-1-79471aa8b898@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-06-30wifi: ath12k: Fix inconsistencies in struct qmi_elem_info initializersRaj Kumar Bhagat
Currently, the struct qmi_elem_info initializers in qmi.c are inconsistent in how they align the assignments, with tabs being used in the majority of places but spaces being used in some places. In those places replace the spaces with tabs for consistency. Also fix incorrect and missing terminating records in the following qmi_elem_info initializers: - qmi_wlanfw_shadow_reg_cfg_s_v01_ei[] - qmi_wlanfw_mem_ready_ind_msg_v01_ei[] - qmi_wlanfw_fw_ready_ind_msg_v01_ei[] Tested-on: Compile tested only. Signed-off-by: Raj Kumar Bhagat <raj.bhagat@oss.qualcomm.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com> Link: https://patch.msgid.link/20260623-qmi-inconsistencies-v1-1-0fc17f2b8338@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-06-30wifi: ath12k: enable threaded NAPI when DP IRQ affinity is unavailableHangtian Zhu
Determine threaded NAPI policy from runtime IRQ capability of the DP MSI IRQ. If irq_can_set_affinity() reports that affinity cannot be set, enable threaded NAPI for DP interrupt groups so datapath processing is not constrained by a single-CPU softirq context. On RB3Gen2, where IRQ affinity is unavailable in the effective IRQ path, EHT160 UDP downlink throughput improved from 802 Mbps to 2.58 Gbps after enabling threaded NAPI. Tested-on: QCC2072 hw1.0 PCI WLAN.COL.1.0.c2-00074-QCACOLSWPL_V1_TO_SILICONZ-1 Signed-off-by: Hangtian Zhu <hangtian.zhu@oss.qualcomm.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Link: https://patch.msgid.link/20260519011627.713068-3-hangtian.zhu@oss.qualcomm.com [Fixed checkpatch "Missing a blank line after declarations"] Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-06-30net: gianfar: dispose irq mappings on probe failure and device removalRosen Penev
irq_of_parse_and_map() creates irqdomain mappings that should be balanced with irq_dispose_mapping(). The driver never called irq_dispose_mapping(), leaking mappings on probe failure and device removal. Fix by adding irq_dispose_mapping() in free_gfar_dev() and expanding its loop from priv->num_grps to MAXGROUPS so the error path also catches partially-initialized groups. All irqinfo pointers are pre-initialized to NULL in gfar_of_init(), making the NULL-guarded walk in free_gfar_dev() safe for every scenario. gfar_parse_group() itself is left as a simple parse function with no resource management; cleanup is centralized in the caller's error path. Assisted-by: opencode:big-pickle Fixes: b31a1d8b4151 ("gianfar: Convert gianfar to an of_platform_driver") Signed-off-by: Rosen Penev <rosenp@gmail.com> Link: https://patch.msgid.link/20260626225228.427392-1-rosenp@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-06-30net: lan743x: Initialize eth_syslock spinlock before useAndrea Righi
lan743x_hardware_init() calls pci11x1x_strap_get_status() during the PCI11x1x probe sequence. That helper acquires the Ethernet subsystem hardware lock via lan743x_hs_syslock_acquire(), which relies on adapter->eth_syslock_spinlock to serialize access. The spinlock is currently initialized only after the strap status is read. With CONFIG_DEBUG_SPINLOCK enabled, taking the zeroed initialized spinlock can trip the spinlock debug check. Fix by initializing adapter->eth_syslock_spinlock before reading the strap status so the probe path never attempts to lock an uninitialized spinlock. Fixes: 46b777ad9a8c ("net: lan743x: Add support to SGMII 1G and 2.5G") Cc: stable@vger.kernel.org # v6.0+ Signed-off-by: Andrea Righi <arighi@nvidia.com> Reviewed-by: David Thompson <davthompson@nvidia.com> Reviewed-by: Thangaraj Samynathan<Thangaraj.s@microchip.com> Link: https://patch.msgid.link/20260626163218.3591486-1-arighi@nvidia.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-06-30net: libwx: fix VMDQ mask for 1-queue modeJiawen Wu
In wx_set_vmdq_queues(), the VMDQ mask was not set for the devices not supporting WX_FLAG_MULTI_64_FUNC, i.e., NGBE devices. A mask of 0 causes __ALIGN_MASK(1, ~vmdq->mask) to return 0, which incorrectly sets q_per_pool to 0 in wx_write_qde(). Fix the VMDQ 1-queue mask to 0x7F then ensures that __ALIGN_MASK(1, ~0x7F) correctly evaluates to 1. Fixes: c52d4b898901 ("net: libwx: Redesign flow when sriov is enabled") Signed-off-by: Jiawen Wu <jiawenwu@trustnetic.com> Reviewed-by: Larysa Zaremba <larysa.zaremba@intel.com> Link: https://patch.msgid.link/161F704D2C983E2C+20260626092530.551028-1-jiawenwu@trustnetic.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-06-30net: airoha: fix max receive size configurationLorenzo Bianconi
Set the GDM maximum receive size to AIROHA_MAX_RX_SIZE unconditionally during hardware initialization instead of updating it according to the configured MTU. This avoids dropping incoming frames that exceed the current MTU but could still be processed by the networking stack, which is able to fragment the reply on the TX side (e.g. ICMP echo requests). Move the per-port MTU configuration to the PPE egress path where it belongs, and set the tx frame size running airoha_ppe_set_xmit_frame_size() to dynamically track the maximum MTU across running interfaces sharing the same PPE instance. Fix the PPE MTU register addressing to pack two port entries per register word and add WAN_MTU0 configuration for non-LAN GDM devices. Fixes: 54d989d58d2a ("net: airoha: Move min/max packet len configuration in airoha_dev_open()") Tested-by: Madhur Agrawal <madhur.agrawal@airoha.com> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://patch.msgid.link/20260625-airoha-fix-rx-max-len-v1-1-45b9b827358d@kernel.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-06-30fsl/fman: Free init resources on KeyGen failure in fman_init()Haoxiang Li
fman_muram_alloc() allocates initialization resources before initializing the KeyGen block. If keygen_init() fails, the function returns -EINVAL directly and leaves those resources allocated. Free the initialization resources before returning from the KeyGen failure path. Fixes: 7472f4f281d0 ("fsl/fman: enable FMan Keygen") Cc: stable@kernel.org Signed-off-by: Haoxiang Li <haoxiang_li2024@163.com> Reviewed-by: Pavan Chebbi <pavan.chebbi@broadcom.com> Reviewed-by: Breno Leitao <leitao@debian.org> Link: https://patch.msgid.link/20260625004834.3394389-1-haoxiang_li2024@163.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-06-29Revert "net: phy: sfp: probe for RollBall I2C-to-MDIO bridge in mdio-i2c"Petr Wozniak
This reverts commit 8fe125892f40 ("net: phy: sfp: probe for RollBall I2C-to-MDIO bridge in mdio-i2c"). That commit added a RollBall bridge probe at MDIO bus creation time, in i2c_mii_init_rollball(), to avoid a multi-minute PHY probe retry loop on modules without a bridge (e.g. RTL8261BE). The probe runs in SFP_S_INIT, before genuine RollBall modules have finished their firmware/bridge initialization, so the bridge does not yet answer CMD_READ/CMD_DONE. The probe times out, mdio_protocol is set to MDIO_I2C_NONE, and PHY detection is then skipped for genuine RollBall modules that worked before the commit. This was confirmed on hardware by Maxime Chevallier and Aleksander Bajkowski: their RollBall modules no longer detect a PHY, and work again on v7.0 (before the bridge probing was introduced). The Sashiko static review flagged the same path. Deferring the probe to PHY discovery time does not fix it either: at that point a slow module may still be initializing, so the probe still returns -ENODEV. A proper fix needs per-module init timing (a longer module_t_wait or a per-module quirk, per SFF-8472 the host must also wait at least 300 ms after insertion), which requires genuine RollBall hardware to develop and validate. Revert to restore the previous, working behaviour in the meantime. The RTL8261BE retry-loop latency that the reverted commit addressed is handled in our downstream tree, so reverting upstream is safe on our side. Fixes: 8fe125892f40 ("net: phy: sfp: probe for RollBall I2C-to-MDIO bridge in mdio-i2c") Reported-by: Aleksander Bajkowski <olek2@wp.pl> Suggested-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Link: https://lore.kernel.org/netdev/20260624084814.20972-1-petr.wozniak@gmail.com/ Signed-off-by: Petr Wozniak <petr.wozniak@gmail.com> Tested-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Link: https://patch.msgid.link/23e3931915c3ed2a14cec95f1490e43d30b225e8.1782581445.git.petr.wozniak@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-29net: phy: sfp: free mii_bus in sfp_i2c_mdiobus_destroyPetr Wozniak
sfp_i2c_mdiobus_create() allocates the I2C MDIO bus with mdio_i2c_alloc(), a plain (non-devm) allocation, and registers it. sfp_i2c_mdiobus_destroy() only unregisters the bus and clears sfp->i2c_mii without calling mdiobus_free(). As the only reference to the bus is then cleared, the struct mii_bus is leaked. This is hit whenever a copper/RollBall SFP module that instantiated an MDIO bus is removed: sfp_sm_main() takes the global teardown path and calls sfp_i2c_mdiobus_destroy(). sfp_cleanup(), on driver unbind, frees sfp->i2c_mii directly, which is why the leak only triggered on module hot-removal and not on unbind. Free the bus in sfp_i2c_mdiobus_destroy() to match the allocation done in sfp_i2c_mdiobus_create(). Fixes: e85b1347ace6 ("net: sfp: create/destroy I2C mdiobus before PHY probe/after PHY release") Signed-off-by: Petr Wozniak <petr.wozniak@gmail.com> Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Reviewed-by: Larysa Zaremba <larysa.zaremba@intel.com> Link: https://patch.msgid.link/312bde8176fc429aa89524e3be250137f034ba84.1782581445.git.petr.wozniak@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-29net: gianfar: dispose irq mappings on probe failure and device removalRosen Penev
irq_of_parse_and_map() creates irqdomain mappings that should be balanced with irq_dispose_mapping(). The driver never called irq_dispose_mapping(), leaking mappings on probe failure and device removal. Fix by adding irq_dispose_mapping() in free_gfar_dev() and expanding its loop from priv->num_grps to MAXGROUPS so the error path also catches partially-initialized groups. All irqinfo pointers are pre-initialized to NULL in gfar_of_init(), making the NULL-guarded walk in free_gfar_dev() safe for every scenario. gfar_parse_group() itself is left as a simple parse function with no resource management; cleanup is centralized in the caller's error path. Signed-off-by: Rosen Penev <rosenp@gmail.com> Link: https://patch.msgid.link/20260626225228.427392-1-rosenp@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-29usbnet: gl620a: fix out-of-bounds read in genelink_rx_fixup()Xiang Mei
genelink_rx_fixup() splits an aggregated RX frame into its individual packets, using a per-packet length taken from device-supplied data. That length is only bounded by GL_MAX_PACKET_LEN (1514); it is never compared against how many bytes were actually received. A malicious GeneLink (GL620A) device can therefore send a short URB whose header claims packet_count > 1 and a first packet of up to 1514 bytes. skb_put_data(gl_skb, packet->packet_data, size); then copies past the end of the receive buffer and hands the adjacent slab contents up the network stack, an out-of-bounds read that leaks kernel heap. No privilege is required: the path runs in the usbnet RX softirq as soon as the interface is up. BUG: KASAN: slab-out-of-bounds in genelink_rx_fixup (drivers/net/usb/gl620a.c:112) Read of size 1514 at addr ffff888011309708 by task ksoftirqd/0/14 Call Trace: ... __asan_memcpy (mm/kasan/shadow.c:105) genelink_rx_fixup (include/linux/skbuff.h:2814 drivers/net/usb/gl620a.c:112) usbnet_bh (drivers/net/usb/usbnet.c:572 drivers/net/usb/usbnet.c:1589) process_one_work (kernel/workqueue.c:3322) bh_worker (kernel/workqueue.c:3405) tasklet_action (kernel/softirq.c:965) handle_softirqs (kernel/softirq.c:622) run_ksoftirqd (kernel/softirq.c:1076) ... skb_pull() already verifies that the requested length fits the buffer and returns NULL otherwise. Move it ahead of the copy and check its result, so a packet that overruns the received data is rejected before it is read. Well-formed frames, whose packets are fully present, are unaffected. Fixes: 47ee3051c856 ("[PATCH] USB: usbnet (5/9) module for genesys gl620a cables") Reported-by: Weiming Shi <bestswngs@gmail.com> Signed-off-by: Xiang Mei <xmei5@asu.edu> Link: https://patch.msgid.link/20260627205353.4000788-1-xmei5@asu.edu Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-29net/mlx5e: macsec: fix use-after-free of metadata_dst on RX SC deleteDoruk Tan Ozturk
When an offloaded MACsec RX SC is deleted, macsec_del_rxsc_ctx() freed the per-SC metadata_dst with metadata_dst_free(), which kfree()s the object unconditionally and ignores the dst reference count. The RX datapath in mlx5e_macsec_offload_handle_rx_skb() looks up the SC under rcu_read_lock() via xa_load(), takes a reference with dst_hold() and attaches the dst to the skb with skb_dst_set(). A reader that already obtained the rx_sc pointer can race with the delete path and operate on freed memory. Fix the owner side by dropping the reference with dst_release() instead of freeing unconditionally, and convert the RX datapath to dst_hold_safe() so a reader racing the SC delete cannot attach a dst whose last reference was just dropped; only attach it when a reference was actually taken. mlx5e_macsec_add_rxsc() also published sc_xarray_element via xa_alloc() before rx_sc->md_dst was allocated and initialised, so a datapath reader that looked the SC up by fs_id could observe rx_sc with md_dst still NULL or, on weakly-ordered architectures, a non-NULL md_dst pointer whose contents were not yet visible. NULL-check the xa_load() result and md_dst on the datapath, and reorder add_rxsc() so the xa_alloc() publish happens only after md_dst is fully initialised; the xarray RCU publish then pairs with the rcu_read_lock()/xa_load() in the datapath. Note: macsec_del_rxsc_ctx() also kfree()s rx_sc->sc_xarray_element without an RCU grace period while the same datapath reads it under rcu_read_lock(); that is a separate pre-existing issue left to a follow-up patch. Found by 0sec automated security-research tooling (https://0sec.ai). Fixes: b7c9400cbc48 ("net/mlx5e: Implement MACsec Rx data path using MACsec skb_metadata_dst") Cc: stable@vger.kernel.org Signed-off-by: Doruk Tan Ozturk <doruk@0sec.ai> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260627223059.29917-1-doruk@0sec.ai Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-29netdevsim: remove ethtool debugfs files before freeing netdevYousef Alhouseen
The ethtool debugfs files point directly into struct netdevsim, which is allocated as net_device private data. Their containing port directory is removed only after nsim_destroy() calls free_netdev(). An open simple-attribute file can consequently dereference the freed private data before the directory is removed. KASAN observed this in debugfs_u32_get() during network namespace teardown. Track and remove the ethtool subtree before free_netdev() on both the normal and registration-failure paths. debugfs removal drains active file users before returning. Fixes: ff1f7c17fb20 ("netdevsim: add pause frame stats") Reported-by: syzbot+6c25f4750230faf70be9@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=6c25f4750230faf70be9 Cc: <stable+noautosel@kernel.org> # netdevsim is a test harness, it's never loaded on production systems Signed-off-by: Yousef Alhouseen <alhouseenyousef@gmail.com> Link: https://patch.msgid.link/20260628002804.24214-1-alhouseenyousef@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-29net: wwan: iosm: bound device offsets in the MUX downlink decoderMaoyi Xie
mux_dl_adb_decode() walks a chain of aggregated datagram tables using offsets and lengths taken from the modem. first_table_index, next_table_index, table_length, datagram_index and datagram_length are all device supplied le values. Only first_table_index was checked, and only for being non zero. The decoder then formed adth = block + adth_index and read the table header and the datagram entries with no bound against the received skb. A modem that reports an index or a length past the downlink buffer makes the decoder read out of bounds. The buffer is IPC_MEM_MAX_DL_MUX_LITE_BUF_SIZE and skb->len is at most that, so skb->len is the real limit, but none of these in band offsets were checked against it. The table chain is also followed with no forward progress check. The loop takes the next table from adth->next_table_index and stops only when that reaches zero. A modem can stage two tables that point at each other, so the loop never ends. It runs in softirq and clones the skb on every pass. Validate every device offset and length against skb->len before use. The block header must fit. Each table header, on entry and after every next_table_index, must lie inside the skb. The datagram table must fit. Each datagram index and length must stay inside the skb. The header padding must not exceed the datagram length so the receive length does not wrap. Require each next_table_index to move forward so the chain cannot cycle. This was reproduced under KASAN as a slab out of bounds read on a normal downlink receive once the iosm net device is up. Fixes: 1f52d7b62285 ("net: wwan: iosm: Enable M.2 7360 WWAN card support") Suggested-by: Loic Poulain <loic.poulain@oss.qualcomm.com> Cc: stable@vger.kernel.org Signed-off-by: Maoyi Xie <maoyixie.tju@gmail.com> Reviewed-by: Simon Horman <horms@kernel.org> Reviewed-by: Loic Poulain <loic.poulain@oss.qualcomm.com> Link: https://patch.msgid.link/178236824878.3259367.5389624724479864947@maoyixie.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-29mlxsw: spectrum_acl_erp: Fix const qualifier of delta_clear()Evgenii Burenchev
mlxsw_sp_acl_erp_delta_clear() takes 'const char *enc_key' but modifies the memory it points to. This is a logical error in the function declaration. The only caller passes a non-const buffer (aentry->ht_key.enc_key), so the const qualifier is misleading and unnecessary. Remove const from the enc_key parameter to match the actual usage. Signed-off-by: Evgenii Burenchev <evg28bur@yandex.ru> Reviewed-by: Petr Machata <petrm@nvidia.com> Link: https://patch.msgid.link/20260625114831.17386-1-evg28bur@yandex.ru Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-29eth: fbnic: don't cache shinfo across skb reallocJakub Kicinski
fbnic_tx_lso() calls skb_cow_head() which may reallocate the skb including the shared info. We can't use the pointer calculated before the call. BUG: KASAN: slab-use-after-free in fbnic_tx_lso.isra.0+0x668/0x8e0 Read of size 4 at addr ff110000262edd98 by task swapper/5/0 Call Trace: fbnic_tx_lso.isra.0+0x668/0x8e0 fbnic_xmit_frame+0x622/0xba0 dev_hard_start_xmit+0xf4/0x620 Allocated by task 8653: __alloc_skb+0x11e/0x5f0 alloc_skb_with_frags+0xcc/0x6c0 sock_alloc_send_pskb+0x327/0x3f0 __ip_append_data+0x188b/0x47a0 ip_make_skb+0x24a/0x300 udp_sendmsg+0x14d2/0x21e0 Freed by task 0: kfree+0x123/0x5a0 pskb_expand_head+0x36c/0xfa0 fbnic_tx_lso.isra.0+0x500/0x8e0 fbnic_xmit_frame+0x622/0xba0 dev_hard_start_xmit+0xf4/0x620 sch_direct_xmit+0x25b/0x1100 The buggy address belongs to the object at ff110000262edc40 which belongs to the cache skbuff_small_head of size 640 The buggy address is located 344 bytes inside of freed 640-byte region [ff110000262edc40, ff110000262ede Link: https://netdev.bots.linux.dev/logs/vmksft/fbnic-qemu-dbg/results/705762/15-uso-py/stderr Fixes: b0b0f52042ac ("eth: fbnic: support TCP segmentation offload") Reviewed-by: Alexander Duyck <alexanderduyck@fb.com> Link: https://patch.msgid.link/20260625160508.3327986-1-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-27net: airoha: dma map xmit frags with skb_frag_dma_map()Lorenzo Bianconi
Map xmit skb fragments using skb_frag_dma_map() instead of dma_map_single(skb_frag_address()). skb_frag_address() relies on page_address() to obtain a kernel virtual address, which is not guaranteed to work for all page types (e.g. highmem pages or user-pinned pages from MSG_ZEROCOPY). skb_frag_dma_map() maps the fragment directly via its struct page and offset through dma_map_page(), avoiding the need for a kernel virtual address entirely. Introduce an enum airoha_dma_map_type to track how each queue entry was mapped (single vs page), so that the matching unmap function is called on completion and in error paths. Fixes: 23020f049327 ("net: airoha: Introduce ethernet support for EN7581 SoC") Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Reviewed-by: Harshitha Ramamurthy <hramamurthy@google.com> Link: https://patch.msgid.link/20260625-airoha-eth-skb_frag_dma_map-v1-1-31d9e460aae6@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-27net: enetc: check the number of BDs needed for xdp_frameWei Fang
The size of xdp_redirect_arr array is ENETC_MAX_SKB_FRAGS. However, the number of fragments contained in xdp_frame may be greater than or equal to ENETC_MAX_SKB_FRAGS, which will cause the access to xdp_redirect_arr to be out of bounds. Fixes: 9d2b68cc108d ("net: enetc: add support for XDP_REDIRECT") Signed-off-by: Wei Fang <wei.fang@nxp.com> Link: https://patch.msgid.link/20260626073244.2168214-1-wei.fang@oss.nxp.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-26qede: fix out-of-bounds check for cqe->len_list[]Matvey Kovalev
Move index check before element access. Fixes: 896f1a2493b5 ("net: qlogic/qede: fix potential out-of-bounds read in qede_tpa_cont() and qede_tpa_end()") Signed-off-by: Matvey Kovalev <matvey.kovalev@ispras.ru> Link: https://patch.msgid.link/20260623144602.3521-1-matvey.kovalev@ispras.ru Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-26net: pse-pd: scope pse_control regulator handle to kref lifetimeCorey Leavitt
__pse_control_release() drops psec->ps via devm_regulator_put(), which only succeeds if the devres entry added by the matching devm_regulator_get_exclusive() is still present on pcdev->dev at the time the pse_control's kref hits zero. That assumption does not hold when the controller is unbound while a pse_control still has consumers: pcdev->dev's devres list is released LIFO, so every per-attach regulator-GET devres runs (and regulator_put()s the underlying regulator) before pse_controller_unregister() itself is invoked. Any later pse_control_put() from that unbind path then reads psec->ps as a dangling pointer inside devm_regulator_put() and WARNs at drivers/regulator/devres.c:232 (devres_release() fails to find the already-released match). The pse_control's consumer handle is logically scoped to the pse_control's refcount, not to pcdev->dev's devres lifetime. Switch to the plain regulator_get_exclusive() / regulator_put() pair so the regulator put in __pse_control_release() no longer depends on the controller's devres still being present. No change to the regulator-framework-visible refcount or lifetime of the underlying regulator: a single get paired with a single put. The existing devm_regulator_register() for the per-PI rails is unchanged (those ARE correctly scoped to the controller's lifetime). This addresses only the regulator handle. The same unbind-while-held scenario also leaves __pse_control_release() reading psec->pcdev->pi[] and psec->pcdev->owner after pse_controller_unregister() has freed pcdev->pi, because the controller does not drain its outstanding pse_control references on unregister. That wider pse_control vs pcdev lifetime problem pre-dates this change and is addressed by the PSE controller notifier series, which drains phydev->psec on PSE_UNREGISTERED before pcdev->pi is freed. Link: https://lore.kernel.org/netdev/20260620112440.1734404-1-github@szelinsky.de/ Fixes: d83e13761d5b ("net: pse-pd: Use regulator framework within PSE framework") Signed-off-by: Corey Leavitt <corey@leavitt.info> Acked-by: Kory Maincent <kory.maincent@bootlin.com> Signed-off-by: Carlo Szelinsky <github@szelinsky.de> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20260624204017.2752934-1-github@szelinsky.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
generated by cgit v1.2.3 (git 2.39.1) at 2026-09-23 02:47:52 +0000