CVE-2026-80934
UnknownSummary
In the Linux kernel, mt7996/mt7992 hand the firmware a HW MAC-TXP for AddBA req action frames but are otherwise FW-TXP devices. On tx free, mt76_connac_txp_skb_unmap() decodes the per-frame txp as a struct mt76_connac_fw_txp, so the unmap loop runs zero times and the skb DMA mapping in buf[1] is never unmapped. Each AddBA req leaks one TX DMA mapping, exhausting the WED swiotlb pool after ~1-2 days under continuous client reconnect churn.
Risk Assessment
The DMA mapping leak exhausts the WED swiotlb pool, after which DMA mapping fails for WED, the WiFi MCU and other on-SoC consumers, causing wireless network failures. An attacker can trigger this by continuously reconnecting clients.
Recommendation
Update the Linux kernel to a version with the fix that adds an mt7996-specific txp unmap inspecting MT_TXD7_MAC_TXD and unmapping buf[1] for MAC-TXP frames.
Other vulnerabilities in Linux kernel (mt76 mt7996 driver)
See all- CVE-2026-80935Unknown
In the Linux kernel, mt7996_mcu_get_eeprom() in the mt76 wifi driver (mt7996 chipset) derives the destination of the EFUSE/EXT block copy from the address reported by the MCU response (event->addr) and clamps only the copy length, never the destination offset into dev->mt76.eeprom.data. A malicious or malfunctioning device can report an arbitrary address and drive an out-of-bounds write of up to MT7996_EXT_EEPROM_BLOCK_SIZE bytes past eeprom.data.
- CVE-2026-80933Unknown
In the Linux kernel, the default EEPROM firmware is parsed and copied as a full EEPROM without checking its length. A truncated file can make the driver read beyond the firmware buffer during variant validation or the fallback copy.
Original NVD description (English source)
In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: fix TX DMA mapping leak for AddBA req frames mt7996/mt7992 hand the firmware a HW MAC-TXP for AddBA req action frames (MT_TXD7_MAC_TXD, set in mt7996_mac_write_txwi_80211()), but are otherwise FW-TXP devices. On tx free mt76_connac_txp_skb_unmap() therefore decodes the per-frame txp as a struct mt76_connac_fw_txp. For a MAC-TXP the fw_txp.nbuf byte aliases the AddBA TID word (MT_TXP1_TID_ADDBA), which is always zero, so the unmap loop runs zero times and the skb DMA mapping in buf[1] is never unmapped. buf[1].skip_unmap is set unconditionally, so the generic DMA-ring cleanup skips it as well. Each AddBA req therefore leaks one TX DMA mapping, roughly one per (re)association. With WED enabled these mappings are bounced through the WED swiotlb pool, so under continuous client reconnect churn the pool is exhausted after ~1-2 days, after which DMA mapping fails for WED, the WiFi MCU and other on-SoC consumers. Keep the deferred (token release) unmap that the design relies on, and add an mt7996-specific txp unmap that inspects MT_TXD7_MAC_TXD and unmaps buf[1] from the MAC-TXP layout for those frames, delegating to mt76_connac_txp_skb_unmap() otherwise.