kernel/git/next/linux-next.git/drivers/net/wireless, branch master

Merge branch 'for-next' of https://git.kernel.org/pub/scm/linux/kernel/git/ath/ath.git

2026-09-08T15:20:46+00:00

Merge branch 'for-next' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next.git

2026-09-08T15:20:44+00:00

Merge branch 'for-next' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless.git

2026-09-08T12:03:56+00:00

treewide: refresh kmalloc_obj() conversions

2026-09-05T04:37:00+00:00

This is another run of the Coccinelle script for converting kmalloc() family of allocations to kmalloc_obj() via the existing rules in scripts/coccinelle/api/kmalloc_objs.cocci This catches both the set of kmalloc() uses added since the first kmalloc_obj() conversions in v7.0 and adds a large group missed in the first pass due to Coccinelle not interacting well with the cleanup.h scoped_...() family of macros[1]. I worked around this with spatch's "--macro-file" argument to a file with all the scoped_...() macros mapped to Coccinelle's YACFE_ITERATOR[2] as that was the closest viable control flow indicator I could find. Build tested allmodconfig on x86, arm64, arm, loongarch, mips, powerpc, riscv, and s390 with no new warnings. Link: https://lore.kernel.org/lkml/202609021314.8A9C0B8@keescook/ [1] Link: https://github.com/coccinelle/coccinelle/blob/master/standard.h [2] Signed-off-by: Kees Cook

wifi: libertas: validate firmware block extents

2026-09-04T10:14:44+00:00

check_fwfile_format() reads each block header and trusts its data length before proving that both fit in the firmware image. A truncated header or oversized block can therefore pass malformed extents to the download path. Require the remaining image to contain the complete header and payload before accepting each block. Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260830140420.26399-1-pengpeng@iscas.ac.cn Signed-off-by: Johannes Berg

wifi: libertas_tf: validate firmware block extents

2026-09-04T10:14:26+00:00

check_fwfile_format() reads each block header and trusts its data length before proving that both fit in the firmware image. A truncated header or oversized block can therefore pass malformed extents to the download path. Require the remaining image to contain the complete header and payload before accepting each block. Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260830124810.97223-1-pengpeng@iscas.ac.cn Signed-off-by: Johannes Berg

wifi: mwifiex: add dt flag to avoid conflict with platform reg domain

2026-09-04T10:11:36+00:00

WRT3200ACM and WRT32x routers always report a fixed US regulatory domain from the mwifiex ROM, which conflicts with the platform regulatory configuration on units sold outside the US market. For example: - phy0 mwlwifi 5 GHz, hard-coded region 98 EU mapped to FR - phy1 mwlwifi 2.4 GHz, hard-coded region 98 EU mapped to FR - phy2 mwifiex 2.4 and 5 GHz, hard-coded region US When the system boots, it detects a conflict between the user selected region and the radios, e.g. BG FR US, and applies extreme restrictions, preventing phy0 from starting on any DFS channel. phy2 works. Add a device-tree flag, which allows affected devices, where the radio conflicts with the platform to ignore the incorrect regulatory hint in the ROM of the radio, so the platform regulatory domain can be used. This does not allow the user to change the regulatory configuration of any radio. It only allows phy0 to start and operate according to its certified configuration. The change affects only platforms which explicitly define this flag, and helps overcome the incorrect behaviour of proprietary radio firmware. The change has been tested on OpenWrt and fixes the issue where phy0 does not start on WRT3200ACM-EU when a DFS channel is used [1] https://github.com/kaloz/mwlwifi/issues/173#issuecomment-307879699 [2] https://github.com/openwrt/openwrt/issues/9956 Signed-off-by: Georgi Valkov Link: https://patch.msgid.link/20260827175850.89395-2-gvalkov@gmail.com Signed-off-by: Johannes Berg

wifi: wfx: fix possible device hang during init

2026-09-04T08:48:49+00:00

The WFxxx device provides an SDIO interface. In addition to the usual in-band SDIO IRQ, the device also supports out-of-band IRQ line. OOB IRQ requires a specific initialization described in commit f00dc1d789e1c ("staging: wfx: poll IRQ during init"): When the chip starts in SDIO mode, the external IRQ (aka Out-Of-Band IRQ) cannot be used before to configure it. Therefore, the first exchanges with the chip have to be done without the OOB IRQ. This patch allow to poll the data until the OOB IRQ is correctly setup. In order to keep the code simpler, this patch also poll data even if OOB IRQ is not used. Commit 57aa557f110d9 ("staging: wfx: introduce a way to poll IRQ") announce some limitation about the data polling mechanism: This function [wfx_bh_poll_irq()] must used with care: if an IRQ fires while the host reads control register, the IRQ can be lost. However, with last analysis, it seems it does not only impact the IRQ. When this condition happen the hardware is lost and won't reply the next commands. The only way to recover the error is to pull the reset pin and bind the device again. Currently wfx_bh_poll_irq() is only used during the two first exchanges with the hardware. Therefore, it has been reported to only happen after a few hours of bind/rebind in a loop. This explain why it has not been reported before. Fortunately, wfx_bh_poll_irq() is only required for OOB IRQ, which is probably very marginal. The In-Band IRQ case also uses this function, but only to simplify the code. This patch limits the use of wfx_bh_poll_irq() to the OOB IRQ. The bus driver now tells wfx_probe() whether polling is necessary. When it is not (in-band SDIO IRQ and SPI), the IRQ is subscribed before the first exchange with the device and wfx_bh_poll_irq() is never called. When it is (SDIO with OOB IRQ), the behavior is unchanged: the control register is polled until the PDS file has configured the IRQ line. To conclude, In-Band users are now safe. Users of OOB IRQ will be still impacted by the bug, but there is nothing we can do (and nobody complained during the last 6 years). Fixes: f00dc1d789e1c ("staging: wfx: poll IRQ during init") Reported-by: Gerard Salvatella Reported-by: Lukas Stockmann Signed-off-by: Jérôme Pouiller Reviewed-by: Alexander Sverdlin Tested-by: Alexander Sverdlin Link: https://patch.msgid.link/20260901083548.113131-2-jerome.pouiller@silabs.com Signed-off-by: Johannes Berg

wifi: p54: require a full exp_if record in PDR_INTERFACE_LIST

2026-09-04T08:12:59+00:00

The PDR_INTERFACE_LIST loop only checks that the record start is within the entry before reading an entire struct exp_if from it. A truncated trailing record makes the if_id/variant reads cross the entry boundary into the heap beyond the EEPROM buffer (verified with a KASAN reproducer of the loop). The variant also feeds the synth front-end selection, so this is not only a leak. Advance only while a full record still fits in the entry. Fixes: eff1a59c48e3 ("[P54]: add mac80211-based driver for prism54 softmac hardware") Cc: stable@vger.kernel.org Acked-by: Christian Lamparter Assisted-by: GLM:5.3 Signed-off-by: Shengzhuo Wei Link: https://patch.msgid.link/20260831-p54-pda-validation-v2-2-dae566b388c8@cherr.cc Signed-off-by: Johannes Berg

wifi: p54: validate curve data length in the calibration curve converters

2026-09-04T08:12:59+00:00

p54_convert_rev0() and p54_convert_rev1() read calibration curve data from the device-supplied EEPROM entry using channel and points-per-channel counts taken verbatim from that same entry, so an entry that declares more data than it carries drives an out-of-bounds read past the EEPROM buffer (verified with a KASAN reproducer of the conversion loop). The sibling converters p54_convert_output_limits() and p54_convert_db() already validate their counts against the entry length; this path was missed. Reject the entry when the counts do not fit in the entry data. Fixes: eff1a59c48e3 ("[P54]: add mac80211-based driver for prism54 softmac hardware") Cc: stable@vger.kernel.org Assisted-by: GLM:5.3 Signed-off-by: Shengzhuo Wei Link: https://patch.msgid.link/20260831-p54-pda-validation-v2-1-dae566b388c8@cherr.cc Signed-off-by: Johannes Berg