CVE-2026-98708: wifi: mac80211: keep paired old chanctx alive
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: keep paired old chanctx alive
An in-place replacement keeps reciprocal replacectx pointers between the old WILLBEREPLACED chanctx and the new REPLACESOTHER chanctx. However, the early free paths only consider assigned and reserved link users when deciding whether to free the old chanctx.
That lets the old chanctx be freed too early while the replacement partner still points back to it, either when the last assigned link is released or when that link successfully reassigns to another existing context. Later unreserve and switch-finalization paths can then follow a stale replacectx pointer.
Keep a paired old chanctx alive until the replacement pair has been torn down. Apply the same check to both ieee80211linkreleasechannel() and ieee80211linkusereservedreassign(). If the replacement is later abandoned, ieee80211linkunreservechanctx() already tears down the pairing before freeing the old chanctx once no users remain.
Affected Software
Event History
Frequently Asked Questions
What systems are exposed to this issue?
Systems running the Linux kernel with the mac80211 Wi-Fi subsystem are relevant. The flaw is exercised in channel-context replacement handling, where an old channel context can remain referenced by its replacement partner after being freed.
What conditions are needed to trigger the stale pointer?
A channel-context replacement must be in progress, followed by release of the last assigned link or successful reassignment of that link to another existing context. Subsequent unreserve or switch-finalization processing can then follow the stale replace_ctx pointer.
What can be done if patching cannot be performed immediately?
The provided information does not specify a configuration workaround. Reducing or avoiding channel-context replacement operations may reduce exposure, but no validated mitigation is stated.
How is the issue fixed?
The fix keeps an old channel context alive while it remains paired with a replacement context, even if it has no assigned or reserved link users. The check is applied in both __ieee80211_link_release_channel() and ieee80211_link_use_reserved_reassign().