CVE-2026-53317

What it actually does

This flaw affects the Linux kernel mt76 driver path for MediaTek MT7921/MT7922 Wi-Fi hardware when operating as an access point. If a station is configured with an association ID greater than 20, the driver/firmware interaction can trigger a Wi-Fi firmware crash. The issue is a denial-of-service condition: it disrupts the wireless interface and can force firmware reset or loss of AP service, but it is not described as enabling code execution, privilege escalation, or data disclosure. The issue was observed on IFTYPE_AP interfaces and is not expected to affect normal station/client mode behavior.

Why it matters to the business

Systems using affected MediaTek MT7921/MT7922 Wi-Fi adapters as Linux-based access points may experience wireless outages if a client association is assigned an unsupported high AID value. In practical terms, this can interrupt connectivity for users or devices relying on the AP, cause instability in embedded/router deployments, and increase operational support burden. The public exploitation likelihood is currently low based on the low EPSS score, lack of KEV listing, and no known exploit maturity, but the impact can still matter for organizations using Linux Wi-Fi AP functionality in branch, IoT, lab, or embedded deployments.

How an attack unfolds

An attacker or misconfigured local AP management component would need to cause the AP interface using mt7921/mt7922 hardware to assign a station AID above 20. The original report describes this occurring with a modified hostapd build that allocated AIDs starting at 65. When such a station configuration reaches the mt76/mt7921 firmware path, the firmware crashes, disrupting AP operation. A remote wireless client alone may not be sufficient if the AP software enforces normal association limits, but an attacker who can influence AP configuration, run a malicious or modified hostapd, or otherwise trigger abnormal AID assignment could repeatedly crash the Wi-Fi firmware and deny wireless service.

How to fix it

Apply a Linux kernel update that includes the mt76/mt7921 fix limiting station AID handling so unsupported AID values do not crash the firmware. Because no exact fixed package versions were provided, use vendor kernel advisories for the relevant distribution, embedded firmware, or OpenWrt-derived build and update to the first version that includes the upstream fix titled "wifi: mt76: mt7921: Place upper limit on station AID." Where immediate patching is not possible, avoid using affected MT7921/MT7922 devices in AP mode, revert modified hostapd behavior that allocates AIDs above normal limits, enforce sane maximum-associated-station settings, and monitor for repeated Wi-Fi firmware resets.

How to confirm the fix worked

Confirm the running kernel or vendor firmware build includes the mt76/mt7921 AID limit fix. Validate that AP software does not assign station AIDs above the supported range and that configuration limits prevent more associations than the driver/firmware can safely support. On test systems only, reproduce the prior failure condition with a controlled AP configuration that would previously allocate high AIDs and verify the Wi-Fi firmware no longer crashes. Review kernel logs after validation for absence of mt7921 firmware crash, reset, timeout, or device restart messages during station association testing.

Typical attack path

1. Identify a Linux system using MediaTek MT7921/MT7922 Wi-Fi hardware in access point mode.
2. Determine whether the AP stack allows or can be coerced into assigning station AIDs greater than 20, such as through modified hostapd behavior or unsafe AP management logic.
3. Associate or configure a station entry that receives an AID above the supported limit.
4. Trigger the mt76/mt7921 driver-to-firmware station configuration path.
5. Cause the Wi-Fi firmware to crash, resulting in AP instability, client disconnections, or wireless service interruption.
6. Repeat the trigger if service recovers, maintaining a denial-of-service condition.

How to detect it

To determine whether this issue may already have been triggered, review kernel logs, system journals, router logs, and AP management logs for mt7921/mt76 firmware crash or reset events occurring at the same time as station association attempts. Useful sources include dmesg, journald, syslog, kern.log, OpenWrt logread output, hostapd logs, and network monitoring that records AP interface resets or mass client disconnects. Look for repeated cycles of station association followed immediately by mt7921 firmware crashes, driver timeouts, hardware resets, AP interface down/up transitions, and hostapd client disconnect storms. Because the vulnerability is a denial-of-service condition rather than a compromise primitive, evidence is likely to appear as availability artifacts rather than persistent malware, new files, credential use, or lateral movement.

• mt7921
• mt76
• firmware crash
• firmware crashed
• Firmware crash
• firmware reset
• firmware restart
• driver own failed
• Timeout for driver own
• hardware restart
• AP-STA-CONNECTED
• AP-STA-DISCONNECTED
• wlan0: AP-STA-DISCONNECTED
• hostapd
• logread | grep -i mt7921
• dmesg | grep -i mt7921
• journalctl -k | grep -i mt76

What your security team should do

• Inventory Linux systems and embedded devices using MediaTek MT7921/MT7922 Wi-Fi hardware, especially those operating in AP mode.
• Prioritize updates for routers, gateways, lab APs, IoT hubs, and embedded systems that expose Wi-Fi AP functionality to untrusted users or devices.
• Patch to a kernel/vendor release containing the mt76/mt7921 station AID limit fix; if unavailable, track the distribution or device vendor advisory until a fixed build is released.
• Review hostapd and AP management customizations, especially OpenWrt-derived or vendor-modified builds, to ensure station AID allocation and maximum station limits remain within safe bounds.
• Add monitoring for repeated mt7921 firmware crashes, AP interface resets, and bursts of client disconnections that may indicate attempted or accidental triggering.
• Treat this as lower urgency than actively exploited remote code execution issues because it is not KEV-listed, has low EPSS, and has no known public exploit maturity, but remediate promptly where Wi-Fi availability is operationally important.