CVE-2026-97432: wifi: iwlwifi: mvm: fix P2P-Device binding handling
In the Linux kernel, the following vulnerability has been resolved:
wifi: iwlwifi: mvm: fix P2P-Device binding handling
Our binding handling for P2P-Device can run into the following scenario, as observed by our testing:
- a station interface is connected on some channel - the P2P-Device does a remain-on-channel (ROC) on that channel - the ROC ends, and the P2P-Device is removed from the binding, but the phyctxt pointer is left around as a PHY cache so we don't need to recalibrate to the channel again and again in case it's not shared - a binding update by the station interface, even a removal, will re-add the P2P-Device to the binding - the P2P-Device is removed, which removes the PHY context, but it's still in the binding so the firmware crashes
Since the P2P device is removed from the binding and only re- added by unrelated code, but we want to keep the phyctxt around as a cache for future ROC usage, fix it by adding a boolean that indicates whether or not the P2P-Device should be added to the binding, and handle that in the binding iterator. That way, the station interface cannot re-add the P2P-Device to the binding when that isn't active.
Affected Software
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Systems using the Linux kernel iwlwifi MVM Wi-Fi driver are exposed when a station interface is connected and a P2P-Device performs remain-on-channel activity on the same channel. The described failure occurs through P2P-Device binding updates involving that interface.
What sequence triggers the firmware crash?
After a P2P-Device remain-on-channel operation ends, its PHY context can remain cached while the device is removed from the binding. A later station-interface binding update can incorrectly re-add the inactive P2P-Device, and subsequent removal of the device removes the PHY context while it remains in the binding, causing firmware to crash.
What does the fix change?
The fix adds state indicating whether the P2P-Device should be included in a binding. Binding iteration then avoids re-adding a P2P-Device that is inactive but retains a cached PHY context for future remain-on-channel use.