0.0
NA
CVE-2026-97432
wifi: iwlwifi: mvm: fix P2P-Device binding handling
Description

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 phy_ctxt 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 phy_ctxt 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.

INFO

Published Date :

Sept. 24, 2026, 5:17 p.m.

Last Modified :

Sept. 25, 2026, 1:17 p.m.

Remotely Exploit :

No

Source :

416baaa9-dc9f-4396-8d5f-8c081fb06d67
Affected Products

The following products are affected by CVE-2026-97432 vulnerability. Even if cvefeed.io is aware of the exact versions of the products that are affected, the information is not represented in the table below.

ID Vendor Product Action
1 Linux linux_kernel
Solution
Modify P2P-Device binding logic to prevent firmware crashes during interface updates.
  • Add a boolean to track P2P-Device binding status.
  • Handle P2P-Device binding in the iterator logic.
  • Ensure station interface updates do not re-add inactive P2P-Devices.
References to Advisories, Solutions, and Tools

Here, you will find a curated list of external links that provide in-depth information, practical solutions, and valuable tools related to CVE-2026-97432.

URL Resource
https://git.kernel.org/stable/c/7be2fc679c8f657868988e41c0bb15bf5a454620
https://git.kernel.org/stable/c/b74e377cad9271950c57472867c469e4b5b2ff0c
CWE - Common Weakness Enumeration

While CVE identifies specific instances of vulnerabilities, CWE categorizes the common flaws or weaknesses that can lead to vulnerabilities. CVE-2026-97432 is associated with the following CWEs:

Common Attack Pattern Enumeration and Classification (CAPEC)

Common Attack Pattern Enumeration and Classification (CAPEC) stores attack patterns, which are descriptions of the common attributes and approaches employed by adversaries to exploit the CVE-2026-97432 weaknesses.

We scan GitHub repositories to detect new proof-of-concept exploits. Following list is a collection of public exploits and proof-of-concepts, which have been published on GitHub (sorted by the most recently updated).

Results are limited to the first 15 repositories due to potential performance issues.

The following list is the news that have been mention CVE-2026-97432 vulnerability anywhere in the article.

The following table lists the changes that have been made to the CVE-2026-97432 vulnerability over time.

Vulnerability history details can be useful for understanding the evolution of a vulnerability, and for identifying the most recent changes that may impact the vulnerability's severity, exploitability, or other characteristics.

  • CVE Modified by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

    Sep. 25, 2026

    Action Type Old Value New Value
    Added Affected Affected value modified. <a href="https://github.com/CVEProject/cvelistV5/blob/main/cves/2026/97xxx/CVE-2026-97432.json">CVE-2026-97432</a>
  • New CVE Received by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

    Sep. 24, 2026

    Action Type Old Value New Value
    Added Description 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 phy_ctxt 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 phy_ctxt 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.
    Added Affected New affected value received. <a href="https://github.com/CVEProject/cvelistV5/blob/main/cves/2026/97xxx/CVE-2026-97432.json">CVE-2026-97432</a>
    Added Reference https://git.kernel.org/stable/c/7be2fc679c8f657868988e41c0bb15bf5a454620
    Added Reference https://git.kernel.org/stable/c/b74e377cad9271950c57472867c469e4b5b2ff0c
EPSS is a daily estimate of the probability of exploitation activity being observed over the next 30 days. Following chart shows the EPSS score history of the vulnerability.