Cloudanix VulnDB

CVE-2026-90376

None

CVSS

—

EPSS

0.2%

Published

Sep 17, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in certain Wi-Fi drivers can cause the wireless hardware to stop responding when multiple connections are active and one enters a low-power state.

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

What it actually does

Incorrect MLD_ID value in MAC TXD and HIF TXP structures triggers firmware busy loop when a third link enters power-save mode, resulting in MCU command timeouts despite normal firmware state.

Why it matters to the business

Wireless connectivity on affected MediaTek hardware can become unresponsive, interrupting network-dependent operations until the device is reset or the driver is reloaded.

How an attack unfolds

An attacker establishes a multi-link setup with a third link placed into power-save mode, then transmits frames that cause the driver to populate an invalid MLD_ID; the firmware enters an infinite loop and stops processing further commands.

How to fix it

Apply the upstream kernel patch that remaps third-link frames to the primary-link WCID and updates packet-ID tracking accordingly; rebuild and deploy the fixed mt76 driver or upgrade to a kernel release containing the fix.

How to confirm the fix worked

Confirm the presence of the remapping logic in the mt7996 driver source; monitor for absence of the "ERROR!! NO PAUSE..." firmware message and successful MCU command completion under multi-link power-save conditions.

Typical attack path

  1. Configure multi-link operation with three or more links on the affected device
  2. Force the third link into power-save state
  3. Transmit frames whose addressing causes the driver to write a non-primary/non-secondary MLD_ID
  4. Observe firmware error log and MCU command timeout, leading to stalled TX processing

How to detect it

Search system and firmware logs for MCU command timeout entries and the exact string "ERROR!! NO PAUSE..."; correlate with multi-link association events and TX status anomalies on mt7996 hardware.

  • ERROR!! NO PAUSE...
  • MCU command timeout
  • mt76: mt7996

What your security team should do

  • Prioritize patching MediaTek mt76-based Wi-Fi devices in production environments
  • Add firmware log monitoring for MCU timeout strings to existing SIEM rules
  • Test the patched driver under multi-link power-save scenarios before broad rollout
  • Track EPSS trend; low current score indicates limited in-the-wild exploitation risk

The record

In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: fix MLD ID in MAC TXD and HIF TXP Problem: MCU command timeout while the firmware state is normal, and the firmware keeps showing the error log "ERROR!! NO PAUSE...". Root cause: If the MLD_ID field in the TXD is neither the primary link id nor the secondary link id, it may lead to a firmware busy loop when the third link is in power saving mode. Remap frames directed to a third link to the primary link wcid. Since TX status events and txfree completions carry the wcid the firmware saw, use the remapped wcid for packet id tracking and non-AQL packet accounting as well, while the frame keeps its original link context for addressing, band and OMAC selection.

Affected packages

Ecosystem Package Introduced Fixed