CVE-2026-90343: wifi: cfg80211: stop PMSR before P2P and NAN teardown
In the Linux kernel, the following vulnerability has been resolved:
wifi: cfg80211: stop PMSR before P2P and NAN teardown
PMSR request teardown must abort active measurements while the wirelessdev is still present in the driver. cfg80211leavelocked() and cfg80211stoppd() already do this before invoking the driver's stop callback, but cfg80211stopp2pdevice() and cfg80211stopnan() do not.
Those helpers are also called directly by nl80211, rfkill shutdown, and wirelessdev unregister paths. If one of these paths stops a P2P device or NAN interface with a pending request, it removes the mac80211 subinterface from the driver first. Subsequent request cleanup cannot reach the lower driver's abort callback, but cfg80211 frees the request regardless. Driver state can then retain a stale request and use it when it later reports a result.
Call cfg80211pmsrwdevdown() before stopping the P2P device or NAN interface. This keeps lower-driver request state and cfg80211 request ownership in sync for all of the helpers' callers.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Linux kernel (cfg80211)to a version that resolves this vulnerability.Patch wifi: cfg80211: stop PMSR before P2P and NAN teardown - Configuration
Update cfg80211 so PMSR request teardown aborts active measurements during P2P/NAN stop paths (cfg80211_stop_p2p_device() and cfg80211_stop_nan()), ensuring lower-driver abort callback is reached and request cleanup is consistent.
cfg80211 PMSR request teardown ordering = Call cfg80211_pmsr_wdev_down() before stopping the P2P device or NAN
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Systems using Linux kernel P2P device or NAN interfaces are exposed when a PMSR request is pending and one of those interfaces is stopped or torn down. The affected teardown paths include direct nl80211 handling, rfkill shutdown, and wireless_dev unregister.
What condition is required to trigger the stale request state?
A P2P device or NAN interface must be stopped while a PMSR measurement request remains active. The teardown can remove the mac80211 subinterface before request cleanup reaches the lower driver's abort callback, leaving stale driver-side request state.
How could an administrator identify a potentially affected event?
Investigate P2P or NAN teardown events that occurred while PMSR requests were pending, particularly during rfkill shutdown, interface unregister, or nl80211-initiated stopping. A later measurement result reported by the driver after teardown is the relevant stale-state scenario.