Cloudanix VulnDB

CVE-2026-80934

None

CVSS

—

EPSS

0.2%

Published

Sep 11, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in certain WiFi hardware drivers can cause wireless network functionality to gradually fail after many devices connect and reconnect repeatedly.

Exploitation
Adjacent Network
Attacker needs
None
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Denial of service
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

A DMA mapping leak occurs for AddBA request frames in mt7996/mt7992 drivers because the unmap function misinterprets the TXP structure, failing to unmap the skb DMA mapping in buf[1], leading to exhaustion of the WED swiotlb pool under high reassociation rates.

Why it matters to the business

Prolonged WiFi instability and eventual failure to allocate DMA mappings for wireless operations after extended periods of client reconnection activity, potentially disrupting network connectivity for users and devices.

How an attack unfolds

An attacker or environmental condition causes repeated client reassociations to the affected WiFi device, each generating an AddBA request frame that leaks a DMA mapping. Over time, this exhausts the shared DMA pool, causing failures in DMA operations for the WiFi subsystem.

How to fix it

Apply the kernel patch that adds mt7996-specific TXP unmap handling for MAC-TXP frames in the mt76 driver to ensure proper unmapping of buf[1] for AddBA frames.

How to confirm the fix worked

Verify the presence of the fix in the mt76 driver source, specifically the addition of mt7996-specific txp unmap logic inspecting MT_TXD7_MAC_TXD before delegating to the generic unmap function.

Typical attack path

  1. Trigger repeated client (re)associations to the mt76-based WiFi device
  2. Each reassociation generates an AddBA req frame leading to a leaked DMA mapping
  3. After sufficient leaks (1-2 days of churn), DMA pool exhaustion occurs, resulting in DoS for WiFi operations

How to detect it

Monitor kernel logs for DMA mapping allocation failures related to WED or mt76 drivers and correlate with patterns of high reassociation rates in WiFi subsystem logs.

What your security team should do

  • Update to a patched Linux kernel version containing the mt76 driver fix
  • Monitor for excessive client reassociation events on affected WiFi hardware
  • Consider disabling WED temporarily if pool exhaustion symptoms appear before patching

The record

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.

Affected packages

Ecosystem Package Introduced Fixed