CVE-2026-80934: wifi: mt76: mt7996: fix TX DMA mapping leak for AddBA req frames
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 (MTTXD7MACTXD, set in mt7996macwritetxwi80211()), but are otherwise FW-TXP devices. On tx free mt76connactxpskbunmap() therefore decodes the per-frame txp as a struct mt76connacfwtxp. For a MAC-TXP the fwtxp.nbuf byte aliases the AddBA TID word (MTTXP1TIDADDBA), which is always zero, so the unmap loop runs zero times and the skb DMA mapping in buf[1] is never unmapped. buf[1].skipunmap 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 MTTXD7MACTXD and unmaps buf[1] from the MAC-TXP layout for those frames, delegating to mt76connactxpskbunmap() otherwise.
Affected Software
Event History
Frequently Asked Questions
Which systems are most likely to be affected in practice?
Systems using the mt7996 or mt7992 Wi-Fi hardware are affected by the described AddBA request handling. The most severe impact described occurs when WED is enabled, because leaked mappings consume the WED swiotlb pool.
What activity causes the resource leak?
Each AddBA request frame leaks one TX DMA mapping, described as occurring roughly once per client association or reassociation. Continuous client reconnect churn can therefore accumulate leaked mappings over time.
What happens if the issue is left unpatched?
With WED enabled, continuous reconnect churn can exhaust the WED swiotlb pool after approximately one to two days. DMA mapping can then fail for WED, the Wi-Fi MCU, and other on-SoC consumers.
Is a reboot likely to be needed to recover after exhaustion?
The provided information says the pool can become exhausted and DMA mapping then fails, but it does not specify a recovery procedure or whether rebooting restores service.