CVE-2026-80938: wifi: mt76: mt7615: avoid waiting for mac work under the mt76 mutex
In the Linux kernel, the following vulnerability has been resolved:
wifi: mt76: mt7615: avoid waiting for mac work under the mt76 mutex
mt7615suspend() acquired the mt76 mutex and then called canceldelayedworksync() on macwork. mt7615macwork() acquires the same mutex via mt7615mutexacquire() at the top of the worker, so if macwork is already running and blocked on the mutex, the suspend path deadlocks waiting for the work it holds the mutex against.
Flush scanwork and macwork before taking the mutex, matching the suspend paths in mt7921 and mt7925. scanwork only takes the mt76 spinlock, but moving it keeps the sequence consistent. This also keeps macwork from running over an already suspended HIF, which the previous split (async cancel under the lock, sync cancel after release) would have allowed.
Affected Software
Event History
Frequently Asked Questions
Which systems are exposed to the suspend deadlock?
The issue affects Linux kernel systems using the mt76 mt7615 Wi-Fi driver path. It can occur when mt7615_suspend() runs while mac_work is already executing and blocked waiting for the mt76 mutex.
What is the operational impact if the race is triggered?
The suspend path can deadlock: it holds the mt76 mutex while synchronously waiting for mac_work, while that worker is waiting to acquire the same mutex. The corrected sequence flushes scan_work and mac_work before taking the mutex and prevents mac_work from operating over an already suspended HIF.