CVE-2026-80938 in Linux
Summary
by MITRE • 09/11/2026
In the Linux kernel, the following vulnerability has been resolved:
wifi: mt76: mt7615: avoid waiting for mac work under the mt76 mutex
mt7615_suspend() acquired the mt76 mutex and then called cancel_delayed_work_sync() on mac_work. mt7615_mac_work() acquires the same mutex via mt7615_mutex_acquire() at the top of the worker, so if mac_work is already running and blocked on the mutex, the suspend path deadlocks waiting for the work it holds the mutex against.
Flush scan_work and mac_work before taking the mutex, matching the suspend paths in mt7921 and mt7925. scan_work only takes the mt76 spinlock, but moving it keeps the sequence consistent. This also keeps mac_work from running over an already suspended HIF, which the previous split (async cancel under the lock, sync cancel after release) would have allowed.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/12/2026
The identified vulnerability in the Linux kernel's mt7615 wireless driver represents a classic concurrency issue rooted in improper mutex locking and workqueue synchronization during device suspension operations. Specifically, the function mt7615_suspend() attempts to acquire the global mt76 mutex before invoking cancel_delayed_work_sync on mac_work. This sequence creates a critical deadlock scenario because the worker routine associated with mac_work, specifically mt7615_mac_work(), also requires acquiring the same mt76 mutex via mt7615_mutex_acquire at its inception. If the mac_work is currently executing and has already blocked while waiting to acquire this mutex when the suspend path initiates, the system enters a state of circular dependency where the suspend thread holds the lock needed by the worker, and the worker holds resources or execution context that prevents it from completing so it can release the lock for the suspend thread. This results in a complete system hang or kernel panic due to unresolvable mutual exclusion contention.
From a technical perspective, this flaw is categorized under CWE-833, which covers Deadlocks, and aligns with ATT&CK technique T1496, Resource Hijacking, as it effectively denies service by freezing the driver's operation and potentially impacting system stability. The root cause lies in the violation of lock ordering principles; developers must ensure that resources are released or flushed before attempting to acquire higher-level locks that might be contested by concurrent execution paths. In this specific implementation, the synchronous cancellation of a delayed work item while holding a mutex that the worker itself needs is fundamentally flawed because cancel_delayed_work_sync waits for the worker to finish, but the worker cannot finish until it acquires the very mutex held by the caller.
The operational impact of this vulnerability extends beyond simple driver failure. Since mt7615 is part of the MediaTek wireless networking stack used in many embedded devices and routers, a deadlock during suspend can lead to system instability when users attempt to put their devices into low-power states or reboot them remotely via network commands that trigger suspension cycles. This could result in data loss if ongoing transmissions are abruptly halted without proper cleanup, or require manual intervention such as hard resets to restore functionality. Furthermore, the previous workaround of splitting the cancellation into asynchronous and synchronous parts under different lock scopes was insufficient because it allowed mac_work to execute over an already suspended Host Interface (HIF), leading to undefined behavior and potential memory corruption due to accessing hardware registers that are no longer powered or responsive.
To mitigate this vulnerability, the resolution involves restructuring the suspend logic to flush both scan_work and mac_work before acquiring the mt76 mutex. This approach ensures that any pending work items are completed or cancelled while holding only lower-level locks like spinlocks, which do not cause such deep contention issues with higher-level mutexes required by other subsystems. By aligning this behavior with the suspend paths in related drivers like mt7921 and mt7925, consistency is maintained across the driver family, reducing maintenance complexity and preventing similar bugs from arising due to inconsistent locking strategies. This change also prevents mac_work from running after the HIF has been suspended, thereby avoiding access to invalid hardware states and ensuring a clean shutdown sequence that preserves system integrity during power management transitions.