Cloudanix VulnDB

CVE-2026-90365

None

CVSS

—

EPSS

0.2%

Published

Sep 17, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A timing bug in certain wireless network drivers can make a computer unstable or crash when the wireless hardware is removed or disabled.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
High
Impact
Privilege Gain
Component
OS kernel
Class
Race Condition
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Race condition allowing reset_work to invoke ieee80211_restart_hw and re-arm mac_work, and rc_work to access station state, after the hardware has been unregistered but before the workqueue is destroyed.

Why it matters to the business

Wireless device removal or driver unload can trigger kernel instability or crashes on affected systems, leading to unexpected downtime and requiring reboots.

How an attack unfolds

An attacker with local access triggers device unregistration (via hot-unplug, module unload, or error path) at a timing that allows pending reset_work or rc_work to execute against torn-down structures, resulting in undefined behavior or denial of service.

How to fix it

Apply the upstream kernel commit that cancels reset_work and rc_work alongside dump_work during device unregister; rebuild and deploy updated kernel images containing the fix.

How to confirm the fix worked

Confirm the cancel_work_sync calls for reset_work and rc_work are present in the mt76_unregister_device path and that no ieee80211_restart_hw or station-state accesses occur after unregister in testing.

Typical attack path

  1. Obtain local access or trigger conditions leading to mt76 device unregistration
  2. Time unregistration to leave reset_work or rc_work queued
  3. Work items execute after hw unregister but before workqueue destruction
  4. ieee80211_restart_hw or station-state access occurs on invalid context

How to detect it

Review kernel logs for oops, warnings, or stack traces involving ieee80211_restart_hw, rc_work, or reset_work after mt76 device unregister events; correlate with device removal or module unload timestamps.

What your security team should do

  • Prioritize kernel updates for systems using mt76 wireless drivers
  • Monitor for kernel oops or panics referencing ieee80211_restart_hw or mt76 work items during device removal
  • Test device hot-unplug and driver unload paths in staging environments before broad deployment

The record

In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: cancel reset and rc work on device unregister Both drivers cancelled dump_work on unregister but left reset_work and rc_work to be flushed only by destroy_workqueue() in mt76_free_device(), which runs after the hw is unregistered and the hardware stopped. A reset_work that fires in that window calls ieee80211_restart_hw() and re-arms mac_work on an unregistered hw, and rc_work touches station state being torn down. Cancel both up front, alongside dump_work.

Affected packages

Ecosystem Package Introduced Fixed