CVE-2026-80938

What it actually does

A lock-order inversion in the MediaTek mt7615 (mt76) WiFi driver can deadlock the Linux kernel during suspend. mt7615_suspend() takes the mt76 mutex and then synchronously cancels mac_work; mt7615_mac_work() needs that same mutex. If the worker is already running and blocked on the mutex, suspend waits forever for work it is holding the lock against. The result is a hung suspend path, possible frozen tasks, and a system that cannot complete sleep or resume without a hard reset. This is an availability defect (local deadlock / DoS), not memory corruption or privilege escalation.

Why it matters to the business

Laptops, embedded systems, and other devices using MediaTek MT7615-class WiFi may hang when entering suspend or sleep, causing unexpected downtime, failed power management, and possible data loss if a hard reboot is required. Likelihood of active exploitation is very low: EPSS is about 0.002 and has been flat for 30 days, the issue is not in CISA KEV, ransomware use is not reported, and exploit maturity is none. Residual risk is operational availability on hosts that suspend while this driver is loaded, not confidentiality or integrity of data.

How an attack unfolds

There is no remote, unauthenticated exploit path. A local actor (or any process that can keep the WiFi MAC worker busy and then force system suspend) races mac_work against the suspend path. If mac_work is running and waiting for the mt76 mutex while suspend already holds it and calls cancel_delayed_work_sync(), both sides block indefinitely. The machine stops completing suspend rather than executing attacker code. No public exploits, named threat actors, or ransomware campaigns are associated with this issue. The same hang can also occur accidentally under normal suspend-with-WiFi-load conditions.

How to fix it

Install a Linux kernel build that includes the mt76 mt7615 suspend fix: flush scan_work and mac_work (cancel delayed work) before acquiring the mt76 mutex, matching the mt7921/mt7925 suspend sequence, so mac_work cannot run over an already suspended HIF. Prefer vendor or distro kernel updates that back-port this change; rebuild out-of-tree mt76 only if you maintain that module yourself. If you cannot patch immediately, reduce exposure by avoiding suspend/hibernate on affected hardware, or by bringing the wireless interface down / unloading the mt7615 module before sleep. There is no configuration-only complete fix.

How to confirm the fix worked

Confirm the running kernel or mt76 module contains the fixed suspend ordering (work flushed before the mutex). On a test system with MT7615 hardware, run repeated suspend/resume cycles while the radio is associated and scanning; the host should sleep and wake without hung tasks. After patching, lockdep should not report mt76 mutex vs. mac_work inversion on the suspend path. Inventory: identify hosts loading mt7615/mt76_core (lsmod, kernel config, hardware IDs) rather than assuming all Linux WiFi devices are affected.

Typical attack path

1. Obtain local access on a Linux host whose WiFi is driven by the mt76 mt7615 driver.
2. Generate concurrent MAC/scan delayed work (normal WiFi activity is sufficient).
3. Trigger system suspend or hibernation while that work may be running.
4. Cause mt7615_suspend() to hold the mt76 mutex and wait on cancel_delayed_work_sync() while mac_work waits for the same mutex.
5. Leave the host deadlocked in the suspend path until a hard reset.

How to detect it

This bug leaves a hung kernel, not a dropped implant, so hunt for availability artifacts rather than malware IOCs. On hosts that froze or required a hard reset around suspend: inspect serial/console logs, pstore/kmsg, journalctl -k, and crash dumps for hung-task reports, mutex waits, and stack traces involving mt7615_suspend, mt7615_mac_work, mt7615_mutex_acquire, and cancel_delayed_work_sync. Look for suspend entry without matching resume, lockdep inversion on the mt76 mutex, and workers still running after HIF suspend. Correlation window is the suspend attempt itself; there is no C2, file drop, or network indicator of compromise. Absence of these logs does not prove the race never occurred if the box was power-cycled before logs flushed.

• mt7615_suspend
• mt7615_mac_work
• mt7615_mutex_acquire
• cancel_delayed_work_sync
• mt76 mutex
• INFO: task blocked for more than
• hung_task: blocked tasks
• PM: suspend entry
• Call Trace: mt7615_

What your security team should do

• Patch Linux kernels and images that ship the mt76 mt7615 driver; treat this as an availability fix, not an emergency KEV-style outage.
• Inventory endpoints, laptops, and embedded/IoT fleets for MT7615-based WiFi and track kernel/package versions until the suspend fix is present.
• If patching is delayed, disable suspend/hibernate or unload mt7615 before sleep on critical systems that must stay recoverable.
• Watch kernel hung-task and suspend-failure telemetry for mt7615_suspend / mac_work; do not expect network IDS signatures.
• Re-test power-management soak tests after the update so the deadlock cannot recur in production images.