CVE-2026-93804: wifi: mac80211: ibss: wait for in-flight TX on disconnect
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: ibss: wait for in-flight TX on disconnect
While leaving an IBSS in ieee80211ibssdisconnect() mac80211 flushes stations, turns the carrier off and immediately tells the driver to leave as well. While there may be synchronizenet() in station flush and in this code later, packets can still be transmitted due to cross-CPU race conditions after carrier off is set. Therefore, it's possible for a race to happen where a TX to the driver occurs while or after telling it to leave the IBSS. This can be confusing to drivers, and in the case of iwlwifi leads to an attempt to use invalid queues.
Move netifcarrieroff() to occur before stainfoflush() during IBSS disconnect, and add synchronizenet() if flushing didn't, so that the synchronizenet() always happens between turning the carrier off and telling the driver, avoiding this race.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Patch wifi: mac80211: ibss: wait for in-flight TX on disconnect
Event History
Frequently Asked Questions
Which systems are exposed to this race condition?
Systems using the Linux kernel's mac80211 stack and disconnecting from an IBSS (ad-hoc) network are exposed. The issue concerns transmit activity that remains in flight during IBSS disconnect processing.
What conditions are needed to trigger the issue?
A packet transmission must race across CPUs with IBSS disconnect handling, allowing a TX request to reach the driver while or after the driver is told to leave the IBSS. The description specifically identifies iwlwifi as a driver that can attempt to use invalid queues in this situation.
How can I determine whether a system is affected?
Review the running kernel's mac80211 IBSS disconnect implementation for ordering that turns the carrier off before station flushing and ensures synchronize_net() occurs before the driver is told to leave. The provided stable-kernel references identify fixes for the issue.