CVE-2026-80936: wifi: mt76: mt7925: cancel mlo_pm_work on stop
In the Linux kernel, the following vulnerability has been resolved:
wifi: mt76: mt7925: cancel mlopmwork on stop
mt7925 queues mlopmwork with a 5 second delay during multi-link power-save setup and never cancels it on the stop path. If the device is torn down inside that window, the work outlives the teardown and its timer fires afterwards, trying to queue onto the workqueue that is already gone:
workqueue: cannot queue mt7925mlopmwork [mt7925common] on wq phy0 WARNING: kernel/workqueue.c:2283 at queuework+0x59/0xa0, CPU#1: swapper/1/0 calltimerfn+0x2a/0x140 runtimers+0x203/0x330 runtimersoftirq+0x86/0xf0
mt7921 already has its own stop callback, so add one for mt7925 that cancels the work before calling mt792xstop(). mt7925ops backs both the PCIe and USB drivers, so this covers both.
Affected Software
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Systems using the Linux kernel mt7925 Wi-Fi driver are affected when the device uses multi-link power-save setup. The mt7925 operations are shared by both PCIe and USB drivers, so the fix applies to both connection types.
What sequence is required to trigger the warning?
The driver must queue its delayed multi-link power-save work, then the mt7925 device must be stopped or torn down within the five-second delay. When the timer subsequently fires, it attempts to queue work on a workqueue that has already been removed.
How can I identify a potentially affected system?
Check kernel logs for a workqueue warning stating that mt7925_mlo_pm_work cannot be queued on a phy workqueue, with a stack involving __queue_work, call_timer_fn, and run_timer_softirq. This indicates delayed work ran after device teardown.
What is the mitigation in the resolved kernel change?
The mt7925 stop path cancels mlo_pm_work before calling mt792x_stop(), preventing the delayed work from surviving teardown. Applying a kernel version containing the referenced stable changes provides the remediation.