UBUNTU-CVE-2026-90365: Low severity ubuntu/linux-hwe-edge vulnerability
In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: cancel reset and rc work on device unregister Both drivers cancelled dumpwork on unregister but left resetwork and rcwork to be flushed only by destroyworkqueue() in mt76freedevice(), which runs after the hw is unregistered and the hardware stopped. A resetwork that fires in that window calls ieee80211restarthw() and re-arms macwork on an unregistered hw, and rcwork touches station state being torn down. Cancel both up front, alongside dumpwork.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
ubuntu/linux-hwe-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42~24.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1~24.04.1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 7.0.0-42.42 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 7.0.0-1016.17 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 7.0.0-1016.18 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oem-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 7.0.0-1015.16 - Upgrade
Upgrade
ubuntu/linux-riscvto a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1 - Compensating control
During device unregister, cancel reset_work and rc_work up front alongside dump_work, before the hardware is unregistered and stopped.
Event History
Frequently Asked Questions
Which systems are realistically exposed to this issue?
Systems running one of the listed Ubuntu kernel packages may be exposed if they use the affected mt76 Wi-Fi drivers. The issue is relevant during device unregister or teardown, when pending driver work can run after the wireless hardware has been unregistered.
What has to occur for the issue to be triggered?
Pending reset_work or rc_work must execute in the interval after the hardware is unregistered and stopped but before the driver workqueue is destroyed. In that window, reset_work can restart an unregistered hardware device and re-arm mac_work, while rc_work can access station state that is being torn down.
Is there a workaround if an updated kernel cannot be deployed immediately?
The provided information does not specify a workaround. Reducing or avoiding mt76 Wi-Fi device unregister and teardown events may reduce exposure, but this is not stated as a supported mitigation.