kernel/git/stable/linux-stable.git/drivers/net/wireless, branch linux-6.12.y

wifi: zd1211rw: reject secondary interfaces to prevent conflicts

2026-09-14T11:32:29+00:00

[ Upstream commit 0e4532ec658606f76f62eb277e7a933919d36cbb ] The zd1211rw driver is designed for single-function Wi-Fi dongles and hardcodes its USB endpoints. When a malformed USB device exposes multiple interfaces that match the driver's device ID, the driver blindly binds to all of them. During probe(), the driver calls usb_reset_device(), which iterates over all interfaces and invokes the pre_reset() callback for each bound interface. Since multiple interfaces are bound to zd1211rw, pre_reset() is called sequentially for each instance, acquiring their respective &mac->chip.mutex. Because all instances initialize their mutexes with the same lock class, lockdep detects a task acquiring a lock of the same class it already holds and flags it as a possible recursive deadlock: WARNING: possible recursive locking detected kworker/0:1/11 is trying to acquire lock: ffff88810371dde0 (&chip->mutex){+.+.}-{4:4}, at: zd_chip_disable_rxtx+0x20/0x50 drivers/net/wireless/zydas/zd1211rw/zd_chip.c:1465 but task is already holding lock: ffff8881138ddde0 (&chip->mutex){+.+.}-{4:4}, at: pre_reset+0x28c/0x380 drivers/net/wireless/zydas/zd1211rw/zd_usb.c:1505 Fix this by explicitly rejecting secondary interfaces (bInterfaceNumber != 0) during probe(). This ensures that only a single instance of the driver binds to the device, eliminating the recursive locking scenario. Fixes: e85d0918b54f ("[PATCH] ZyDAS ZD1211 USB-WLAN driver") Assisted-by: Gemini:gemini-3.5-flash Gemini:gemini-3.1-pro-preview syzbot Reported-by: syzbot+0ec3d1a6cf1fbe79c153@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=0ec3d1a6cf1fbe79c153 Link: https://syzkaller.appspot.com/ai_job?id=00724ef7-fd77-4cde-9779-895b8f63c2f6 Signed-off-by: Slawomir Stepien Link: https://patch.msgid.link/20260730065231.1644030-1-sst@poczta.fm Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin

wifi: ath10k: snoc: use memcpy_fromio() for MSA ramdump

2026-09-14T11:32:29+00:00

[ Upstream commit 4f25071afe9218aaae1c63fbf75e229aa6405319 ] On WCN3990/SNOC the MSA region is mapped with devm_memremap(MEMREMAP_WT). On arm64 such a mapping is not Normal-cacheable, so unaligned accesses to it are not permitted. ath10k_msa_dump_memory() copies the region with a plain memcpy(), whose optimized __pi_memcpy_generic implementation issues wide/unaligned loads. This triggers an alignment fault (FSC=0x21) Oops in ath10k_snoc_fw_crashed_dump() while collecting the devcoredump: Unable to handle kernel paging request ... FSC=0x21: alignment fault pc : __pi_memcpy_generic lr : ath10k_snoc_fw_crashed_dump [ath10k_snoc] The Oops both leaves the firmware RAM dump buffer zeroed (no dump is captured) and crashes the kernel, which in turn breaks modem SSR recovery. Use memcpy_fromio(), which only performs accesses that are valid for such a device-memory mapping. The generic memcpy_fromio() implementation aligns the source before issuing word-sized reads and stores the destination with put_unaligned(), so it is also safe for the coherent DMA allocation used on the non-reserved-memory path. ath11k and ath12k use the same pattern when copying target memory into crash dumps, so call it unconditionally here too. The MEMREMAP_WT pointer is a plain void *, so an explicit __iomem cast is needed; use __force to keep sparse happy. Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.3.3.7.c5-00107-QCAHLSWMTPL-1 Fixes: 3f14b73c3843 ("ath10k: Enable MSA region dump support for WCN3990") Signed-off-by: Linghui Wu Reviewed-by: Rameshkumar Sundaram Reviewed-by: Baochen Qiang Link: https://patch.msgid.link/20260727072629.2297208-1-linghui.wu@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin

wifi: mt76: mt7925: Fix EHT Beamformee SS subfields to meet 802.11be minimum

2026-09-14T11:32:28+00:00

[ Upstream commit 404c4e564f6b1eeffd10bf2b2d3b86620f5794c3 ] Per IEEE 802.11be, the Beamformee SS <= 80/160/320 MHz 3-bit subfields in the EHT PHY Capabilities are encoded as (Nss - 1) and are required to be >= 3 (i.e. at least 4 SS receive capability) whenever SU Beamformee is advertised. MT7925 is a 2x2 STA (sts = 2), so directly filling (sts - 1) = 1 violates the spec minimum. Clamp the encoded value to 3 when sts <= 3, otherwise use (sts - 1). This is applied consistently to the BEAMFORMEE_SS <= 80 MHz (split across phy_cap_info[0]/[1]), <= 160 MHz and <= 320 MHz (6 GHz only) subfields. Fixes: c948b5da6bbe ("wifi: mt76: mt7925: add Mediatek Wi-Fi7 driver for mt7925 chips") Signed-off-by: shengwei.lu Link: https://patch.msgid.link/20260723031108.2017653-1-jb.tsai@mediatek.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin

wifi: mt76: mt7925: advertise EHT 320MHz capabilities for 6GHz band

2026-09-14T11:32:28+00:00

[ Upstream commit 77833c57a33450c0409e4b90d7721d255ea23a9e ] mt7925_init_eht_caps() only populates EHT MCS/NSS maps for BW <= 80 and BW = 160, but never sets BW = 320. This means iw phy shows no 320MHz MCS map entries even though the hardware supports 320MHz operation in the 6GHz band. Add the missing 320MHz capability bits for 6GHz: - PHY_CAP0: IEEE80211_EHT_PHY_CAP0_320MHZ_IN_6GHZ - PHY_CAP1: beamformee SS for 320MHz - PHY_CAP2: sounding dimensions for 320MHz - PHY_CAP6: MCS15 support for 320MHz width - MCS/NSS: populate bw._320 maps for 6GHz band Introduce is_320mhz_supported() to gate 320MHz on MT7927 only, since MT7925 does not support 320MHz operation. Tested-by: Marcin FM Tested-by: Cristian-Florin Radoi Tested-by: George Salukvadze Tested-by: Evgeny Kapusta <3193631@gmail.com> Tested-by: Samu Toljamo Tested-by: Ariel Rosenfeld Tested-by: Chapuis Dario Tested-by: Thibaut François Tested-by: 张旭涵 Reviewed-by: Sean Wang Signed-off-by: Javier Tia Link: https://patch.msgid.link/20260425195011.790265-6-sean.wang@kernel.org Signed-off-by: Felix Fietkau Stable-dep-of: 404c4e564f6b ("wifi: mt76: mt7925: Fix EHT Beamformee SS subfields to meet 802.11be minimum") Signed-off-by: Sasha Levin

wifi: mt76: mt7915: report RX chain signal for all RX paths

2026-09-14T11:32:28+00:00

[ Upstream commit b53c44fe65792608f58028c7b0953e610ad652ee ] status->chains was set from the antenna mask, which is derived from the number of spatial streams, while the chain_signal array is filled from all RCPI fields. On boards where the number of RX paths exceeds the stream count, e.g. the 3T3R mt7916/mt7981 variant with 2 streams on the 5 GHz band, the RSSI of the extra chains was never reported. Use the band local RX path chainmask instead. Fixes: e57b7901469f ("mt76: add mac80211 driver for MT7915 PCIe-based chipsets") Link: https://patch.msgid.link/20260727150434.1778520-9-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin

wifi: mt76: mt7915: fix chainmask handling for non-dbdc phys on band 1

2026-09-14T11:32:28+00:00

[ Upstream commit ea891799eccc9e43ebba0dc157d4b197ad6c1a0e ] On single-adie mt7986 the only phy is bound to band 1, but its chainmask is stored unshifted, because dev->chainshift is still zero while the eeprom is parsed for the main phy. mt7915_set_antenna() on the other hand shifts by chainshift * band_idx, so the representation of the chainmask changed as soon as the antenna configuration was touched. Until then, mt7915_mcu_set_chan_info() passed rx_path = 0 to the firmware, since shifting the unshifted mask down clears all bits. Keep the unshifted form for that case and add helpers for the band local chainmask, so that only the band 1 phy of a dbdc device uses the shifted form. Fixes: 3eb50cc90534 ("wifi: mt76: mt7915: rely on band_idx of mt76_phy") Link: https://patch.msgid.link/20260727150434.1778520-8-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin

wifi: mt76: mt7996: fix reg addr remap when addr is 0

2026-09-14T11:32:28+00:00

[ Upstream commit eb906eeff2d1e84b628dc210dada325269c71383 ] When addr is less than the hardcoded threshold in __mt7996_reg_addr, it indicates that remapping is unnecessary. Currently, the flow remaps address 0x0 to MT_HIF_REMAP_BASE_L2, which is incorrect. To address this, modify __mt7996_reg_addr to return INVALID_REG_ADDR if the address is not below the hardcoded value or is not present in the mt7996_reg_map array. Additionally, update the remap condition to check if addr is equal to INVALID_REG_ADDR. Fixes: 3687854d3e7e ("wifi: mt76: mt7996: add locking for accessing mapped registers") Signed-off-by: StanleyYP Wang Link: https://patch.msgid.link/20260727150434.1778520-5-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin

wifi: mt76: mt7915: release hif2 reference on probe IRQ failure

2026-09-14T11:32:28+00:00

[ Upstream commit 8370aebd26a9dfa2e0de665e3ab504c0e97ee730 ] The hif2 reference obtained by mt7915_pci_init_hif2() is only released on error paths that key off dev->hif2, which is not assigned until after the IRQ setup. If pci_alloc_irq_vectors() or the primary devm_request_irq() fails, the reference leaks. Drop it explicitly on those paths via mt7915_put_hif2(). Fixes: f68d67623dec ("mt76: mt7915: add Wireless Ethernet Dispatch support") Link: https://patch.msgid.link/20260727150434.1778520-4-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin

wifi: mt76: mt7915: fix ext PHY use-after-free on register error path

2026-09-14T11:32:28+00:00

[ Upstream commit 15b960014f24dce5388d4a2e7274e6490cb3c421 ] After mt7915_register_ext_phy() succeeded, a failure of the main PHY mt7915_init_debugfs() or mt7915_coredump_register() unwound through free_phy2, which called ieee80211_free_hw() on the ext PHY hw while it was still registered with mac80211, since mt76_unregister_device() only unregisters the main hw. Unregister the ext PHY (thermal + phy + hw) first and skip the redundant free. Fixes: 7b8e1ae886e4 ("mt76: mt7915: rework hardware/phy initialization") Link: https://patch.msgid.link/20260727150434.1778520-3-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin

wifi: mt76: mt7915: fix double hif2 init on the non-WED path

2026-09-14T11:32:28+00:00

[ Upstream commit 3ae8ad277e2819a281b0e36b55633c8515c16ce7 ] mt7915_pci_init_hif2() was called unconditionally and again inside the WED-inactive branch. The helper increments the global hif_idx, writes the PCIe RECOG_ID register and takes a get_device() reference via mt7915_pci_get_hif2(), while removal only drops one reference. On non-WED dual-hif hardware this double-incremented hif_idx, wrote RECOG_ID twice and leaked a device reference. Only the call inside the WED-inactive branch is correct; drop the unconditional one. hif2 is already initialised to NULL. Fixes: cacdd67812c6 ("mt76: mt7915: add mt7915_mmio_probe() as a common probing function") Link: https://patch.msgid.link/20260727150434.1778520-2-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin