summaryrefslogtreecommitdiff
path: root/drivers/net
AgeCommit message (Collapse)AuthorFilesLines
2026-07-24wifi: rtw89: coex: Add firmware 0.27.97.X support for RTL8852CChing-Te Ku1-0/+9
Newer firmware is using the new TLV-Header format, without this patch it will lead driver run into length mismatch state. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260717065739.64124-14-pkshih@realtek.com
2026-07-24wifi: rtw89: coex: Add wifi role info version 101Ching-Te Ku3-5/+125
The structure active_role which describes the using Wi-Fi role format is different with the exist v1. Add branch to cover the difference. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260717065739.64124-13-pkshih@realtek.com
2026-07-24wifi: rtw89: coex: Add cycle status report version 105Ching-Te Ku2-0/+218
The exists version 5 format has FDDT(frequency divided training) related information. But the feature wasn't support for RTL8852C now, so firmware will not send the related reference value. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260717065739.64124-12-pkshih@realtek.com
2026-07-24wifi: rtw89: coex: Add slots version 2Ching-Te Ku3-20/+51
Slots structure version 2 uses new TLV-Header to package slots information, patch related entry for version 2. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260717065739.64124-11-pkshih@realtek.com
2026-07-24wifi: rtw89: coex: Add TDMA version 4Ching-Te Ku1-3/+5
TDMA version 4 uses new TLV-Header to package TDMA information, patch related entry for version 4. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260717065739.64124-10-pkshih@realtek.com
2026-07-24wifi: rtw89: coex: Add firmware 0.29.133.X support for RTL8852B familyChing-Te Ku1-0/+27
The new firmware modified GPIO setup structure format for third party chip set I/O control & offloaded Wi-Fi TRX status to firmware for training traffic RF-Parameters & TDMA mechanism. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260717065739.64124-9-pkshih@realtek.com
2026-07-24wifi: rtw89: coex: Fix Wi-Fi role info H2C command header issueChing-Te Ku1-2/+6
The function to filled up H2C command data is the last step in the driver, the next step is going to firmware. So the structure version number should not included driver local branch number (like firmware is v5, but driver branch to v105), it should be assigned as a explicit version number which paired with firmware. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260717065739.64124-8-pkshih@realtek.com
2026-07-24wifi: rtw89: coex: Add driver info H2C command index version 103Ching-Te Ku1-6/+7
The 0.29.133.X firmware driver info H2C index maximum is 5, to prevent switch case fall through and send unexpected H2C commands, add version code 103 as judgment. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260717065739.64124-7-pkshih@realtek.com
2026-07-24wifi: rtw89: coex: Refine chip initial related structureChing-Te Ku11-474/+411
Due to the firmware version become more and more, the version divided branch coding method make the related code scattered everywhere, and too much version macro, rearrange the code, assign the value to version format only when H2C commands. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260717065739.64124-6-pkshih@realtek.com
2026-07-24wifi: rtw89: coex: Branch out version 105 firmware report map indexChing-Te Ku1-0/+11
RTL8852B in firmware 0.29.133.X do not support BT-TX-PWR report, re-index and branch out to version 105. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260717065739.64124-5-pkshih@realtek.com
2026-07-24wifi: rtw89: coex: Fix unexpected grant-signal assigneeChing-Te Ku1-12/+12
The C2H report is for knowing what the grant-signal setting is now, not for applying new grant-signal setting. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260717065739.64124-4-pkshih@realtek.com
2026-07-24wifi: rtw89: coex: Add version 9 report control infoChing-Te Ku2-6/+178
WiFi firmware will save its build date/time and package into C2H event then send to driver. It helps to analyze what kind of firmware was loaded now. Remove unnecessary memory set. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260717065739.64124-3-pkshih@realtek.com
2026-07-24wifi: rtw89: coex: Add version 107 TX/RX info for firmware featureChing-Te Ku3-37/+126
The previous version 7 format is for Dual-Bluetooth using. This patch is for single Bluetooth solution using. Driver will summary Wi-Fi now status for firmware to train RF parameters & TDMA mechanism. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260717065739.64124-2-pkshih@realtek.com
2026-07-24wifi: rtw89: phy: set CFR to manual mode for some 2GHz channelsPing-Ke Shih1-1/+7
The CFR (Channel Frequency Response) manual mode condition for 2GHz is missing to limit on bandwidth for specific channels, which are channel 13 with 20MHz bandwidth and channel 11 with 40MHz bandwidth. Also add a band check to avoid affecting 5GHz/6GHz bands. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260717061910.54466-10-pkshih@realtek.com
2026-07-24wifi: rtw89: 8922d: reduce IO in power-on functionPing-Ke Shih1-9/+9
To improve initial time, merge some IO to reduce IO times. Two registers are: 1. R_BE_SYS_PW_CTRL: 0x4[12:11]=0, 0x4[18]=1, 0x4[15]=0, and 0x4[10]=0 2. R_BE_SYS_ADIE_PAD_PWR_CTRL: Merge 0x18[6] and 0x18[5] Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260717061910.54466-9-pkshih@realtek.com
2026-07-24wifi: rtw89: pci: set PCIe maximum TS1 for RTL8922DEPing-Ke Shih2-1/+11
Set TS1 (training sequence 1) to 1024 when PCIe enters recovery state to improve RF interference while entering and leaving L1ss. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260717061910.54466-8-pkshih@realtek.com
2026-07-24wifi: rtw89: wow: extend timeout unit to avoid SER false alarmPing-Ke Shih1-1/+1
With original timeout unit, it might trigger SER false alarm causing WiFi card lost. Extend timeout unit to avoid wrong SER. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260717061910.54466-7-pkshih@realtek.com
2026-07-24wifi: rtw89: 8922d: bypass TXIQK when scanChih-Kang Chang3-2/+73
When connected to an AP and a scan is triggered, the FW may fail to transmit probe request because switching channels may load an uninitialized TXIQK table. Therefore, bypass TXIQK during scanning to avoid using invalid calibration values. Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260717061910.54466-6-pkshih@realtek.com
2026-07-24wifi: rtw89: rfk: update TXIQK H2C command format to v1Chih-Kang Chang3-11/+32
TX IQK is a RF calibration, the v1 format adds a field for the thermal re-calibration parameter for RTL8922D after FW 0.35.113.0. Update the format accordingly. Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260717061910.54466-5-pkshih@realtek.com
2026-07-24wifi: rtw89: 8852cu: add quirk to disable 2.4 GHz bandDavid Lee3-1/+6
Add RTW89_QUIRK_DISABLE_2GHZ to the rtw89_quirks enum to allow per-device suppression of the 2.4 GHz band. Apply the quirk only for the 0x28de:0x2432 (VID:PID) USB device, which operates only in 5/6 GHz bands. Signed-off-by: David Lee <sc.lee@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260717061910.54466-4-pkshih@realtek.com
2026-07-24wifi: rtw89: add multicolor LED support for RTL8852CU valve boardJohnson Tsai20-6/+207
Add multicolor LED support for the RTL8852CU valve board to reflect wireless connection status (by default, green LED is ON when associated and OFF when disconnected). Extend the rtw89 LED subsystem with a multicolor path via led_classdev_mc, for board-level variants with more than one LED GPIO channel. Add a new RTW89_LEDS_MC Kconfig option and support multicolor LEDs through led_classdev_mc, with per-channel caching to minimize redundant register writes. The RTL8852CU valve board is wired up as the first user, driving a multicolor WRGB LED over four GPIO channels (8, 18, 16, and 17) that map to LED_COLOR_ID_WHITE/RED/GREEN/BLUE. Usage: - Auto-triggered (default): Green LED ON when connected, OFF when disconnected - Manual override (e.g., set red; channel order: WHITE RED GREEN BLUE): echo "0 1 0 0" > /sys/class/leds/rtw89-phyX-multicolor/multi_intensity echo 1 > /sys/class/leds/rtw89-phyX-multicolor/brightness Signed-off-by: Johnson Tsai <wenjie.tsai@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260717061910.54466-3-pkshih@realtek.com
2026-07-24wifi: rtw89: add LED support to reflect the wireless association statusJohnson Tsai7-0/+181
Add a new RTW89_LEDS Kconfig option, along with LED structures to describe flexible GPIO mappings for chip common LED definition. Core LED lifecycle and registration logic default to the mac80211 association trigger, and chips are wired up as the first user with a single-GPIO monochrome LED. Usage: - Auto-triggered (default): ON when connected, OFF when disconnected - Manual override: echo <1|0> > /sys/class/leds/rtw89-phyX/brightness Signed-off-by: Johnson Tsai <wenjie.tsai@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260717061910.54466-2-pkshih@realtek.com
2026-07-24wifi: rtw89: pci: enable 36-bit DMA on spacemit K3Anirudh Srinivasan1-0/+4
The Spacemit K3 Pico ITX Board has a RTL8852BE pcie card behind a PCIe root port, but the SoC doesn't have any 32 bit DMA addreseses which the rtw89 seems to use by default. Enable 36 bit DMA ability that the driver has when this particular root port is detected so that the driver can probe on this SoC. Tested-by: Aurelien Jarno <aurelien@aurel32.net> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Anirudh Srinivasan <asrinivasan@oss.tenstorrent.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260716-rtw89-spacemit-k3-v2-2-392b577ebf75@oss.tenstorrent.com
2026-07-23Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski151-604/+1692
Cross-merge networking fixes after downstream PR (net-7.2-rc5). Conflicts: drivers/net/amt.c 3656a79f94c47 ("amt: re-read skb header pointers after every pull") 586c4dcf28eb6 ("amt: no longer rely on RTNL in amt_fill_info()") https://lore.kernel.org/amIaJr3aOQNS_Fvl@sirena.org.uk Adjacent changes: drivers/net/geneve.c 8efb8f8bbb35 ("geneve: require CAP_NET_ADMIN in the device netns for changelink") 0ba269933f73 ("geneve: convert config to RCU-protected pointer") Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-23net: dsa: microchip: Fix log typo in error pathNiklas Söderlund1-1/+1
All other log messages in the driver prefix hex values with 0x, add it in the one missing message. While at it also add the missing opening parenthesis in the same log message. Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20260722174853.2316333-1-niklas.soderlund+renesas@ragnatech.se Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-23Merge branch 'mlx5-next' of ↵Jakub Kicinski2-14/+4
git://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linux Tariq Toukan says: ==================== mlx5-next updates 2026-07-22 * 'mlx5-next' of git://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linux: net/mlx5: Add PSP related fields to the mlx5_ifc net/mlx5: Drop redundant esw_cap, reuse e_switch_cap ==================== Link: https://patch.msgid.link/20260722071030.1693021-1-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-23wifi: iwlwifi: bump core version for BZ/SC/DRMiri Korenblit3-3/+3
Start supporting Core 107 FW on these devices. Link: https://patch.msgid.link/20260723142324.ed92b1d7f927.I6dd10d2f9a04a36751aea9e238fecfa62fe280a6@changeid Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
2026-07-23wifi: iwlwifi: regulatory: add LARI v15 DSM support bitmapPagadala Yesu Anjaneyulu4-4/+21
Firmware API v15 extends LARI config with the DSM function-0 support bitmap, and host must provide this information for regulatory handling. Without this, FW cannot use BIOS-reported DSM capability bits. Add oem_supported_dsm_bitmap to the host LARI config command definition and wire it into regulatory command construction. Populate it from DSM query data and keep backward compatibility by using the pre-v15 command size for command version 14. Behavior change: When DSM function-0 data is available, host includes it in the LARI config command sent to FW; older command versions remain compatible. Signed-off-by: Pagadala Yesu Anjaneyulu <pagadala.yesu.anjaneyulu@intel.com> Link: https://patch.msgid.link/20260723142324.c576a8c7560b.I5cc1277d0ef31409f6a3364342a3f35cd9318ceb@changeid Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
2026-07-23bnge/bng_re: fix ring ID widthsVikas Gupta6-34/+33
Firmware requires more than 16 bits to address TX ring IDs for its internal QP management. Widen the associated HSI ring ID fields to 32 bits. The values firmware assigns remain within 24 bits, bounded by the hardware doorbell XID field. The fw_ring_id field belongs to bnge_ring_struct, a common struct shared by all ring types, so widening it to u32 applies uniformly across TX, RX, CP, and NQ rings but firmware assigns values within 16-bit range for all ring types except TX, which requires the wider field. Note that, Thor Ultra hardware has not yet been deployed and no firmware has been released to field, so backward compatibility is not a concern. Fixes: 42d1c54d6248 ("bnge/bng_re: Add a new HSI") Signed-off-by: Vikas Gupta <vikas.gupta@broadcom.com> Reviewed-by: Siva Reddy Kallam <siva.kallam@broadcom.com> Reviewed-by: Dharmender Garg <dharmender.garg@broadcom.com> Reviewed-by: Yendapally Reddy Dhananjaya Reddy <yendapally.reddy@broadcom.com> Link: https://patch.msgid.link/20260721063731.2622500-1-vikas.gupta@broadcom.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-23Merge tag 'ovpn-net-20260720' of https://github.com/OpenVPN/ovpn-net-nextJakub Kicinski3-11/+15
Antonio Quartulli says: ==================== Included fixes: * ensure keepalive timestamps are computed using monotonic source * avoid UAF in unlock_ovpn() when iterating over release_list * fix memleak in selftest tool * ensure reference to peer is acquired before scheduling worker (which may drop the not-yet-taken ref) * fix refcount leak in case of concurrent TX and RX TCP error * fix potential refcount unbalance in case of sock release in P2P mode * tag 'ovpn-net-20260720' of https://github.com/OpenVPN/ovpn-net-next: ovpn: use monotonic clock for peer keepalive timeouts ovpn: fix use after free in unlock_ovpn() selftests/net: ovpn: fix getaddrinfo memory leak in ovpn_parse_remote() ovpn: hold peer before scheduling keepalive work ovpn: fix peer refcount leak in TCP error paths ovpn: avoid putting unrelated P2P peer on socket release ==================== Link: https://patch.msgid.link/20260720144131.3657121-1-antonio@openvpn.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-23net: airoha: fix ETS channel derivation in airoha_tc_setup_qdisc_ets()Lorenzo Bianconi1-2/+1
Derive the hardware QoS channel from opt->parent instead of opt->handle in airoha_tc_setup_qdisc_ets(). The ETS qdisc handle is either user-specified or auto-allocated by qdisc_alloc_handle() and bears no relation to the HTB leaf classid that identifies the hardware channel. HTB derives the channel from TC_H_MIN(opt->classid), and ETS is always attached as a child of an HTB leaf, so its opt->parent matches that classid. Using opt->handle instead can cause two ETS qdiscs on different HTB leaves to collide on the same hardware channel, corrupting scheduler configuration and stats. Fixes: 20bf7d07c956 ("net: airoha: Add sched ETS offload support") Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://patch.msgid.link/20260720-airoha-ets-handle-fix-v2-1-6f7129ddc06f@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-23net: slip: serialize receive against buffer reallocationSungmin Kang1-0/+4
sl_realloc_bufs() replaces rbuff and updates buffsize while holding sl->lock. slip_receive_buf() reads those fields and writes through rbuff without holding the lock. An MTU change can therefore race with receive processing. An MTU shrink can expose the new smaller rbuff with the old larger bound, causing an out-of-bounds write. A receive callback which already loaded the old rbuff can instead continue writing after that buffer has been freed. Serialize receive processing with sl_realloc_bufs() by holding sl->lock while consuming each receive batch. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Sungmin Kang <726ksm@gmail.com> Link: https://patch.msgid.link/20260718073631.1674-1-726ksm@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-23idpf: fix max_vport related crash on allocation error during initEmil Tantilov1-1/+6
Set adapter->max_vports only after successful allocation of vports, netdevs and vport_config buffers. This fixes possible crashes on reset or rmmod, following failed allocation on init [ 305.981402] idpf 0000:83:00.0: enabling device (0100 -> 0102) [ 305.994464] idpf 0000:83:00.0: Device HW Reset initiated [ 320.416872] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 320.416918] #PF: supervisor read access in kernel mode [ 320.416942] #PF: error_code(0x0000) - not-present page [ 320.416963] PGD 2099657067 P4D 0 [ 320.416983] Oops: Oops: 0000 [#1] SMP NOPTI ... [ 320.417093] RIP: 0010:idpf_remove+0x118/0x200 [idpf] [ 320.417130] Code: 8b bb 98 09 00 00 e8 17 0f 5b e5 48 8b bb e8 08 00 00 e8 0b 0f 5b e5 66 83 bb 28 06 00 00 00 48 8b bb 20 06 00 00 74 49 31 ed <48> 8b 04 ef 48 85 c0 74 2f 48 8b 78 20 e8 66 58 91 e5 48 8b 83 20 [ 320.417183] RSP: 0018:ff7322212903fdb8 EFLAGS: 00010246 [ 320.417205] RAX: 0000000000000000 RBX: ff4463de40300000 RCX: ff7322212903fd4c [ 320.417228] RDX: 0000000000000001 RSI: ffffffffa7f7d100 RDI: 0000000000000000 [ 320.417250] RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 [ 320.417272] R10: 0000000000000001 R11: ff4463de3a638f58 R12: ff4463be89ac7000 [ 320.417294] R13: ff4463be89ac7198 R14: ff4463be94fc7198 R15: ffffffffc0f10f20 [ 320.417317] FS: 00007f963c0e6740(0000) GS:ff4463fdd65d8000(0000) knlGS:0000000000000000 [ 320.417342] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 320.417362] CR2: 0000000000000000 CR3: 00000020ba674002 CR4: 0000000000773ef0 [ 320.417385] PKRU: 55555554 [ 320.417398] Call Trace: [ 320.417412] <TASK> [ 320.417429] pci_device_remove+0x42/0xb0 [ 320.417459] device_release_driver_internal+0x1a9/0x210 [ 320.417492] driver_detach+0x4b/0x90 [ 320.417516] bus_remove_driver+0x70/0x100 [ 320.417539] pci_unregister_driver+0x2e/0xb0 [ 320.417564] __do_sys_delete_module.constprop.0+0x190/0x2f0 [ 320.417592] ? kmem_cache_free+0x31e/0x550 [ 320.417619] ? lockdep_hardirqs_on_prepare+0xde/0x190 [ 320.417644] ? do_syscall_64+0x38/0x6b0 [ 320.417665] do_syscall_64+0xc8/0x6b0 [ 320.417683] ? clear_bhb_loop+0x30/0x80 [ 320.417706] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 320.417727] RIP: 0033:0x7f963bb30beb Fixes: 0fe45467a104 ("idpf: add create vport and netdev configuration") Reviewed-by: Madhu Chittim <madhu.chittim@intel.com> Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Reviewed-by: Simon Horman <horms@kernel.org> Tested-by: Samuel Salin <Samuel.salin@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Link: https://patch.msgid.link/20260717185340.3595286-13-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-23ice: reject out-of-range ptype in ice_parser_profile_initAleksandr Loktionov1-0/+3
set_bit(rslt->ptype, prof->ptypes) operates on a DECLARE_BITMAP of ICE_FLOW_PTYPE_MAX (1024) bits. Nothing prevents a malicious VF from providing ptype >= 1024 through VIRTCHNL, resulting in a write past the end of the bitmap and a kernel page fault. Reproduced with a custom kernel module injecting a crafted VIRTCHNL_OP_ADD_RSS_CFG on E810-C QSFP (8086:1592), FW 4.91 0x800214af 1.3909.0, ICE COMMS DDP 1.3.53.0, kernel 7.1.0-rc1. crash_parser: ice_parser_profile_init @ ffffffffc0d61b60 crash_parser: setting ptype=0xffff (max valid=1023) crash_parser: calling ice_parser_profile_init -- expect OOB crash! BUG: kernel NULL pointer dereference, address: 0000000000000000 Oops: Oops: 0002 [#1] SMP NOPTI CPU: 56 UID: 0 PID: 165011 Comm: insmod Kdump: loaded Tainted: G S U OE 7.1.0-rc1 #1 Hardware name: Intel Corporation S2600BPB/S2600BPB RIP: 0010:ice_parser_profile_init+0x2d/0x1d0 [ice] Call Trace: <TASK> ? __pfx_ice_parser_profile_init+0x10/0x10 [ice] crash_init+0x127/0xff0 [crash_parser] do_one_initcall+0x45/0x310 do_init_module+0x64/0x270 init_module_from_file+0xcc/0xf0 idempotent_init_module+0x17b/0x280 __x64_sys_finit_module+0x6e/0xe0 Bail out early with -EINVAL when ptype is out of range. Fixes: e312b3a1e209 ("ice: add API for parser profile initialization") Cc: stable@vger.kernel.org Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Reviewed-by: Marcin Szycik <marcin.szycik@linux.intel.com> Tested-by: Rafal Romanowski <rafal.romanowski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Link: https://patch.msgid.link/20260717185340.3595286-12-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-23ice: prevent tstamp ring allocation for non-PF VSI typesPaul Greenwalt1-0/+3
The pf->txtime_txqs bitmap tracks which Tx queues have ETF (Earliest TxTime First) offload enabled. This bitmap is indexed by queue number and is set by ice_offload_txtime(), which only operates on PF VSI queues. However, ice_is_txtime_ena() does not check the VSI type before consulting the bitmap. When ETF offload is enabled on PF Tx queue 0, bit 0 is set in pf->txtime_txqs. During a subsequent PCI reset rebuild, the CTRL VSI's Tx queue 0 is reconfigured and ice_is_txtime_ena() is called for that ring. Since it only checks pf->txtime_txqs by queue index without distinguishing VSI type, it finds bit 0 set and returns true, matching the PF VSI's ETF queue, not the CTRL VSI's. This causes ice_vsi_cfg_txq() to spuriously allocate a tstamp_ring for the CTRL VSI ring. Since CTRL VSI rings have no associated netdev, ice_clean_tx_ring() takes an early return at the !netdev check before reaching ice_free_tx_tstamp_ring(), leaking the allocation. Each PCI reset leaks one 64-byte tstamp_ring. Fix this by restricting ice_is_txtime_ena() to return true only for PF VSI rings, since txtime_txqs is only meaningful for PF VSI queues. Fixes: ccde82e90946 ("ice: add E830 Earliest TxTime First Offload support") Signed-off-by: Paul Greenwalt <paul.greenwalt@intel.com> Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.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/20260717185340.3595286-11-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-23ice: fix PTP Call Trace during PTP releasePaul Greenwalt1-0/+5
If a PF reset occurs when the PTP state is ICE_PTP_UNINIT, then ice_ptp_rebuild() will update the state to ICE_PTP_ERROR. This will result in the following PTP release call trace during driver unload: kernel BUG at lib/list_debug.c:52! ice_ptp_release+0x332/0x3c0 [ice] ice_deinit_features.part.0+0x10e/0x120 [ice] ice_remove+0x100/0x220 [ice] This was observed when passing PF1 through to a VM. ice_ptp_init() fails because ctrl_pf is NULL and sets the state to ICE_PTP_UNINIT. Fix by detecting the ICE_PTP_UNINIT state in ice_ptp_rebuild() and returning without error, preventing the invalid state transition to ICE_PTP_ERROR. The only valid path to ICE_PTP_ERROR is from ICE_PTP_RESETTING after a failed rebuild. Fixes: 8293e4cb2ff5 ("ice: introduce PTP state machine") Cc: stable@vger.kernel.org Signed-off-by: Paul Greenwalt <paul.greenwalt@intel.com> Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Reviewed-by: Simon Horman <horms@kernel.org> 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/20260717185340.3595286-10-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-23ice: use READ_ONCE() to access cached PHC timeSergey Temerkhanov1-1/+1
ptp.cached_phc_time is a 64-bit value updated by a periodic work item on one CPU and read locklessly on another. On 32-bit or non-atomic architectures this can result in a torn read. Use READ_ONCE() to enforce a single atomic load. Fixes: 77a781155a65 ("ice: enable receive hardware timestamping") Cc: stable@vger.kernel.org Signed-off-by: Sergey Temerkhanov <sergey.temerkhanov@intel.com> Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Reviewed-by: Simon Horman <horms@kernel.org> 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/20260717185340.3595286-9-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-23ice: fix LAG recipe to profile associationMarcin Szycik1-1/+1
ice_init_lag() associates recipes to profiles, assuming that Link Aggregation-related profiles will always have profile ID lower than 70 (ICE_PROFID_IPV6_GTPU_IPV6_TCP_INNER). This value seems arbitrary and might not always be valid for some versions of DDP package, i.e. LAG profiles may have profile ID greater than 70. This would lead to misconfigured switch and LAG not working properly. Fix it by checking up to maximum profile ID. Fixes: 1e0f9881ef79 ("ice: Flesh out implementation of support for SRIOV on bonded interface") Signed-off-by: Marcin Szycik <marcin.szycik@linux.intel.com> Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Reviewed-by: Dave Ertman <david.m.ertman@intel.com> Reviewed-by: Simon Horman <horms@kernel.org> 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/20260717185340.3595286-7-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-23ice: pass the return value of skb_checksum_help()Michal Swiatkowski1-11/+9
skb_checksum_help() can fail. Pass its return value back to the caller. Commonize this software path in goto. Instead of just returning error try calculating software checksum first. There is a check for TSO in checksum_sw_fb. Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Signed-off-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.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/20260717185340.3595286-4-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-23ice: allow creating VFs when !CONFIG_ICE_SWITCHDEVVincent Chen3-10/+10
Currently ice_eswitch_attach_vf() is called unconditionally in ice_start_vfs(), which causes VF creation to fail when CONFIG_ICE_SWITCHDEV is not defined. Fix this by adding switchdev mode checks at the call sites before calling ice_eswitch_attach_vf(), consistent with how ice_eswitch_attach_sf() is already handled in ice_devlink_port_new(). This is similar to commit aacca7a83b97 ("ice: allow creating VFs for !CONFIG_NET_SWITCHDEV") which fixed the same issue for the previous ice_eswitch_configure() API. Fixes: 415db8399d06 ("ice: make representor code generic") Signed-off-by: Vincent Chen <vincent.chen@sifive.com> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Tested-by: Rafal Romanowski <rafal.romanowski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Link: https://patch.msgid.link/20260717185340.3595286-2-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-23octeontx2-pf: tc: fix egress ratelimitingHariprasad Kelam1-13/+16
The egress rate calculation computes an incorrect mantissa and exponent, causing up to ~50% deviation from the configured rate at lower speeds. Rework the computation to follow the hardware rate formula: rate = 2 * (1 + mantissa/256) * 2^exp / (1 << div_exp) Keep div_exp = 0 and derive exp and mantissa from half of the requested rate. Rates below 2 Mbps are floored to the smallest encodable step (exp = 0, mantissa = 0). Fixes: e638a83f167e ("octeontx2-pf: TC_MATCHALL egress ratelimiting offload") Signed-off-by: Hariprasad Kelam <hkelam@marvell.com> Signed-off-by: Nitin Shetty J <nshettyj@marvell.com> Link: https://patch.msgid.link/20260717084349.2227796-1-nshettyj@marvell.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-23net/mlx5e: Reject unsupported CB Shaper TSA in ETS validationAlexei Lazar1-0/+8
Credit Based (CB) TSA is not supported by the mlx5 driver, so reject any configurations that specify it. Fixes: 08fb1dacdd76 ("net/mlx5e: Support DCBNL IEEE ETS") Signed-off-by: Alexei Lazar <alazar@nvidia.com> Reviewed-by: Carolina Jubran <cjubran@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Pavan Chebbi <pavan.chebbi@broadcom.com> Link: https://patch.msgid.link/20260717075125.1244877-3-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-23net/mlx5e: Report zero bandwidth for non-ETS traffic classesAlexei Lazar1-0/+7
The IEEE 802.1Qaz standard defines that bandwidth allocation percentages only apply to Enhanced Transmission Selection (ETS) traffic classes. For STRICT and VENDOR transmission selection algorithms, bandwidth percentage values are not applicable. Currently for non-ETS 100 bandwidth is being reported for all traffic classes in the get operation due to hardware limitation, regardless of their TSA type. Fix this by reporting 0 for non-ETS traffic classes. Fixes: 820c2c5e773d ("net/mlx5e: Read ETS settings directly from firmware") Signed-off-by: Alexei Lazar <alazar@nvidia.com> Reviewed-by: Carolina Jubran <cjubran@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Pavan Chebbi <pavan.chebbi@broadcom.com> Link: https://patch.msgid.link/20260717075125.1244877-2-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-23net: pcs: xpcs: fix SGMII state readingCoia Prant1-25/+7
Commit 2a22b7ae2fa3 ("net: pcs: xpcs: adapt Wangxun NICs for SGMII mode") added a path in xpcs_get_state_c37_sgmii() that reads speed/duplex from BMCR after AN completes. However, BMCR does not reflect the negotiated result on the hardware where this has been tested: - On RK3568 (MAC side SGMII), BMCR returns a fixed hardware reset value - Wangxun engineer Jiawen Wu confirmed that on their side, "BMCR looks like it only wants to be return as 0" [0] The correct information is available in CL37_ANSGM_STS, which contains the actual link status and negotiated speed/duplex. This bug was previously masked by phylink core, which overrides the PCS link state with the PHY state when a PHY is present: /* If we have a phy, the "up" state is the union of both the * PHY and the MAC */ if (phy) link_state.link &= pl->phy_state.link; Thus, when the link is down, the PHY's link_down state is applied on top of whatever the PCS reports, hiding the broken PCS state reading path. Modify xpcs_get_state_c37_sgmii() to: 1. Read link state from CL37_ANSGM_STS 2. If link is up, report speed/duplex from CL37_ANSGM_STS 3. Remove the broken BMCR reading path entirely Also properly set state->an_complete to reflect the AN completion status, and clear CL37_ANCMPLT_INTR when link is down to avoid stale state. [0] https://lore.kernel.org/all/000c01dd1593$2ac0b0f0$804212d0$@trustnetic.com/ Fixes: 2a22b7ae2fa3 ("net: pcs: xpcs: adapt Wangxun NICs for SGMII mode") Cc: stable@vger.kernel.org Tested-by: Jiawen Wu <jiawenwu@trustnetic.com> Signed-off-by: Coia Prant <coiaprant@gmail.com> Tested-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Link: https://patch.msgid.link/20260717074324.3250043-2-coiaprant@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-23net/mlx5: E-Switch, fix zero num_dest in prio_tag egress vlan ruleYael Chemla1-1/+1
esw_egress_acl_vlan_create() hardcodes num_dest=0 in its mlx5_add_flow_rules() call. When invoked from the non-bond path fwd_dest is NULL and num_dest=0 is correct. When invoked from esw_acl_egress_ofld_rules_create() during a bond event, fwd_dest is non-NULL and flow_act.action carries MLX5_FLOW_CONTEXT_ACTION_FWD_DEST, but _mlx5_add_flow_rules() rejects a non-NULL dest pointer paired with dest_num<=0 and returns -EINVAL. The error propagates as "configure slave vport egress fwd, err(-22)". The passive vport's egress ACL table ends up with its flow groups allocated but no FTEs, so prio-tagged packets are not popped and bond failover is broken on prio_tag_required devices. Fix by passing fwd_dest ? 1 : 0 as num_dest to match the actual number of destinations supplied. Fixes: bf773dc0e6d5 ("net/mlx5: E-Switch, Introduce APIs to enable egress acl forward-to-vport rule") Signed-off-by: Yael Chemla <ychemla@nvidia.com> Reviewed-by: Cosmin Ratiu <cratiu@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260717073306.1242399-1-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-23net/mlx5: Fix MCIA register buffer overflow on 32 dword readsGal Pressman1-2/+2
The MCIA register can return up to 32 dwords (128 bytes) when the device advertises the mcia_32dwords capability, but struct mlx5_ifc_mcia_reg_bits only defines dword_0..11, leaving room for just 12 dwords (48 bytes) of data. mlx5_query_mcia() clamps the read size to mlx5_mcia_max_bytes() and then memcpy()s that many bytes out of the register, potentially reading past the end of the 'out' buffer. On kernels built with FORTIFY_SOURCE this is caught as a buffer overflow while reading the module EEPROM via ethtool: detected buffer overflow in memcpy kernel BUG at lib/string_helpers.c:1048! RIP: 0010:fortify_panic+0x13/0x20 Call Trace: mlx5_query_mcia.isra.0+0x200/0x210 [mlx5_core] mlx5_query_module_eeprom_by_page+0x4a/0xa0 [mlx5_core] mlx5e_get_module_eeprom_by_page+0xbb/0x120 [mlx5_core] eeprom_prepare_data+0xf3/0x170 ethnl_default_doit+0xf1/0x3b0 Extend the mcia_reg layout to 32 dwords. Fixes: 271907ee2f29 ("net/mlx5: Query the maximum MCIA register read size from firmware") Signed-off-by: Gal Pressman <gal@nvidia.com> Reviewed-by: Alex Lazar <alazar@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260717072338.1240582-1-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-23geneve: require CAP_NET_ADMIN in the device netns for changelinkDoruk Tan Ozturk1-0/+3
A tunnel changelink() operates on at most two netns, dev_net(dev) and the sticky underlay netns geneve->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in geneve->net can rewrite a geneve device whose underlay lives in geneve->net. geneve_changelink() applies the new configuration against geneve->net: geneve_link_config() and the geneve_quiesce()/geneve_unquiesce() pair reopen the underlay sockets in that netns (geneve_sock_add() uses geneve->net), so the same reasoning as the tunnel changelink series applies here. Gate geneve_changelink() with rtnl_dev_link_net_capable(), at the top of the op before any attribute is parsed, matching ipgre_changelink() and the rest of the "require CAP_NET_ADMIN in the device netns for changelink" series. Found by 0sec automated security-research tooling (https://0sec.ai). Fixes: 5b861f6baa3a ("geneve: add rtnl changelink support") Cc: stable@vger.kernel.org Signed-off-by: Doruk Tan Ozturk <doruk@0sec.ai> Reviewed-by: Fernando Fernandez Mancera <fmancera@suse.de> Link: https://patch.msgid.link/20260716203500.70573-3-doruk@0sec.ai Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-23vxlan: require CAP_NET_ADMIN in the device netns for changelinkDoruk Tan Ozturk1-0/+3
A tunnel changelink() operates on at most two netns, dev_net(dev) and the sticky underlay netns vxlan->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in vxlan->net can rewrite a vxlan device whose underlay lives in vxlan->net. vxlan_changelink() validates and applies the new configuration against vxlan->net (vxlan_config_validate(vxlan->net, ...)) and can reopen the underlay socket in that netns, so the same reasoning as the tunnel changelink series applies here. Gate vxlan_changelink() with rtnl_dev_link_net_capable(), at the top of the op before any attribute is parsed, matching ipgre_changelink() and the rest of the "require CAP_NET_ADMIN in the device netns for changelink" series. Found by 0sec automated security-research tooling (https://0sec.ai). Fixes: 8bcdc4f3a20b ("vxlan: add changelink support") Cc: stable@vger.kernel.org Signed-off-by: Doruk Tan Ozturk <doruk@0sec.ai> Reviewed-by: Fernando Fernandez Mancera <fmancera@suse.de> Link: https://patch.msgid.link/20260716203500.70573-2-doruk@0sec.ai Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-23hinic: remove unused ethtool RSS user configuration buffersChenguang Zhao2-23/+0
rss_indir_user and rss_hkey_user are allocated and filled in __set_rss_rxfh() when the user configures RSS via ethtool, but nothing ever reads them. hinic_get_rxfh() fetches the state from the device, and the hardware is programmed from the original indir/key arguments. These buffers only leaked on driver unload. Drop the unused allocations, memcpys, and struct fields. Fixes: 4fdc51bb4e92 ("hinic: add support for rss parameters with ethtool") Signed-off-by: Chenguang Zhao <zhaochenguang@kylinos.cn> Reviewed-by: Joe Damato <joe@dama.to> Link: https://patch.msgid.link/20260722025353.328179-1-chenguang.zhao@linux.dev Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-23pppoe: reload header pointer after dev_hard_header()Asim Viladi Oglu Manizada1-0/+1
pppoe_sendmsg() saves a pointer to the PPPoE header before calling dev_hard_header(). Device header callbacks are allowed to reallocate the skb head, invalidating pointers into it. This can happen when a send is blocked in copy_from_user() while the first non-Ethernet port is added to an empty team device. The team's delegated GRE header callback then expands the skb head. PPPoE subsequently writes six bytes through the stale pointer into the freed head. Reload the PPPoE header through the skb's network-header offset after device header creation. pskb_expand_head() updates that offset when it relocates the head. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Asim Viladi Oglu Manizada <manizada@pm.me> Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev> Reviewed-by: Eric Dumazet <edumazet@google.com> Link: https://patch.msgid.link/20260722093814.3017176-1-manizada@pm.me Signed-off-by: Jakub Kicinski <kuba@kernel.org>
generated by cgit (git 2.54.0.dirty) at 2026-09-23 12:09:38 +0000