CVE-2026-89523: wifi: mt76: mt7925: cancel pending mlo_pm_work
In the Linux kernel, the following vulnerability has been resolved:
wifi: mt76: mt7925: cancel pending mlopmwork
If the device is reset, suspended or unregistered within that window, the pending work can still run and access vif/bss data that may already be freed, or send MCU commands while the firmware is not available.
Add canceldelayedworksync(&dev->mlopmwork) in all relevant teardown and suspend paths:
- mt7925macresetwork() (chip reset recovery) - mt7925eunregisterdevice() (PCIe unbind) - mt7925pcisuspend() (PCIe bus suspend) - mt7925suspend() (mac80211 suspend) - mt7925ususpend() (USB bus / runtime suspend)
This ensures the work is stopped before the device state becomes invalid.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Add cancel_delayed_work_sync(&dev->mlo_pm_work) to all relevant teardown paths: mt7925_mac_reset_work(), mt7925_pci_suspend(), mt7925_suspend(), mt7925e_unregister_device(), and mt7925u_suspend(), so pending mlo_pm_work cannot run when the device is reset/suspended/unregistered and MCU/firmware is unavailable.
Linux kernel wifi: mt76 (mt7925) cancel_delayed_work_sync(&dev->mlo_pm_work) in teardown paths (mt7925_mac_reset_work, mt7925_pci_suspend, mt7925_suspend, mt7925e_unregister_device, mt7925u_suspend) = add cancel_delayed_work_sync(&dev->mlo_pm_work)
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Systems using the Linux mt76 mt7925 Wi-Fi driver are exposed when the device is reset, suspended, or unregistered while mlo_pm_work is still pending. The affected teardown paths include PCIe unbind and suspend, mac80211 suspend, USB or runtime suspend, and chip reset recovery.
What conditions are required for the issue to occur?
A delayed mlo_pm_work task must remain pending during a device reset, suspend, or unregister event. The task can then run after vif or bss data has been freed, or when firmware is unavailable.
What can be done if the fix cannot be applied immediately?
The provided data identifies reset, suspend, runtime suspend, and device-unregister transitions as the relevant exposure windows. No supported workaround or configuration-based mitigation is provided.