CVE-2026-80936

What it actually does

Failure to cancel a delayed work item (mlo_pm_work) during device teardown leaves a timer that attempts to schedule work on a destroyed workqueue after the mt7925 driver instance is freed, resulting in a use-after-free condition in the kernel workqueue subsystem.

Why it matters to the business

Local users on affected systems can trigger kernel warnings, crashes, or potential privilege escalation, leading to denial of service or full system compromise on Linux devices using mt7925 Wi-Fi hardware.

How an attack unfolds

An attacker with local access triggers multi-link power-save setup to arm the 5-second delayed work, then forces rapid device teardown (e.g., via interface down or driver unload) before the timer fires; the subsequent callback attempts to queue onto the already-released workqueue, causing the use-after-free.

How to fix it

Update to a Linux kernel containing the fix that adds an mt7925 stop callback to cancel mlo_pm_work before calling mt792x_stop; backport the patch to any distribution kernels still shipping the vulnerable mt7925 driver.

How to confirm the fix worked

Confirm the presence of the stop callback that explicitly cancels mlo_pm_work, verify no 'workqueue: cannot queue mt7925_mlo_pm_work' warnings appear during repeated interface up/down cycles, and test that the module can be unloaded cleanly without timer callbacks.

Typical attack path

1. Obtain local shell or user context on the target Linux system
2. Trigger mt7925 multi-link power-save setup to queue the delayed work
3. Force driver or interface teardown within the 5-second window
4. Trigger the stale timer to execute the freed workqueue callback
5. Leverage resulting memory corruption for privilege escalation or crash

How to detect it

Search kernel logs and dmesg for 'workqueue: cannot queue mt7925_mlo_pm_work' and 'WARNING: kernel/workqueue.c' entries around mt7925 teardown events; inspect crash dumps for use-after-free signatures in workqueue code paths.

What your security team should do

• Prioritize kernel updates for all systems exposing mt7925 hardware
• Restrict local user access on multi-user or shared Linux workstations until patched
• Monitor kernel logs for workqueue warnings related to mt7925_mlo_pm_work
• Apply the fix in any custom or downstream kernels before deployment