Answer in brief
CVE-2026-64176 records a Unknown severity vulnerability in wifi: iwlwifi: mvm: fix driver-set TX rates on old devices. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=3592c0083fb29cca13cd9978b8844d58b4eff548 <6fe92651b44fd3cfc8dcfdaad0e82885c384dada || >=3592c0083fb29cca13cd9978b8844d58b4eff548 <6b58a79f2cd98156856eb49e8b55db5facdd7e6d || >=3592c0083fb29cca13cd9978b8844d58b4eff548 <fb84b5cbcaab3ca0f4e961d92a40ed7f3aac483b || c6c14c2b08e9c4c82e1ec39ef3e8b9ec845ac7fd || >=6.17.9 <6.18 | 6fe92651b44fd3cfc8dcfdaad0e82885c384dada, 6b58a79f2cd98156856eb49e8b55db5facdd7e6d, fb84b5cbcaab3ca0f4e961d92a40ed7f3aac483b, 6.18 |
| Linux/Linuxgeneric | 6.18 | Not reported |
Published upstream
Jul 19, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 5, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 5, 2026
In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: fix driver-set TX rates on old devices On old devices such as 7265D, rates are still encoded in version 1 format, which doesn't use the CCK/OFDM rate index (0-3/0-7) but rather their PLCP value (e.g. 10 for 1 Mbps CCK rate.) While introducing v3 rates, I changed the driver from internally handling v1 rates and converting to v2, to internally handling v3 and converting to v1 or v2 according to the firmware. I accordingly changed the code in iwl_mvm_mac80211_idx_to_hwrate() to no longer have different values for different APIs. This was correct. However, I later reverted this part of the change, because it was reported that I had broken beacon rates, causing a FW assert/crash. This caused TX_CMD rates to be set incorrectly, potentially causing a warning when reported back from the device as having been used. Fix this (hopefully correctly now) by handling beacon rates in the TX_CMD that's embedded in the beacon template command separately. Restore iwl_mvm_mac80211_idx_to_hwrate() to return only the rate index, not PLCP value, fixing the real TX_CMD.
Quoted source text, attributed separately from HOL analysis.
Answer in brief
CVE-2026-64176 records a Unknown severity vulnerability in wifi: iwlwifi: mvm: fix driver-set TX rates on old devices. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=3592c0083fb29cca13cd9978b8844d58b4eff548 <6fe92651b44fd3cfc8dcfdaad0e82885c384dada || >=3592c0083fb29cca13cd9978b8844d58b4eff548 <6b58a79f2cd98156856eb49e8b55db5facdd7e6d || >=3592c0083fb29cca13cd9978b8844d58b4eff548 <fb84b5cbcaab3ca0f4e961d92a40ed7f3aac483b || c6c14c2b08e9c4c82e1ec39ef3e8b9ec845ac7fd || >=6.17.9 <6.18 | 6fe92651b44fd3cfc8dcfdaad0e82885c384dada, 6b58a79f2cd98156856eb49e8b55db5facdd7e6d, fb84b5cbcaab3ca0f4e961d92a40ed7f3aac483b, 6.18 |
| Linux/Linuxgeneric | 6.18 | Not reported |
Published upstream
Jul 19, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 5, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 5, 2026
In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: fix driver-set TX rates on old devices On old devices such as 7265D, rates are still encoded in version 1 format, which doesn't use the CCK/OFDM rate index (0-3/0-7) but rather their PLCP value (e.g. 10 for 1 Mbps CCK rate.) While introducing v3 rates, I changed the driver from internally handling v1 rates and converting to v2, to internally handling v3 and converting to v1 or v2 according to the firmware. I accordingly changed the code in iwl_mvm_mac80211_idx_to_hwrate() to no longer have different values for different APIs. This was correct. However, I later reverted this part of the change, because it was reported that I had broken beacon rates, causing a FW assert/crash. This caused TX_CMD rates to be set incorrectly, potentially causing a warning when reported back from the device as having been used. Fix this (hopefully correctly now) by handling beacon rates in the TX_CMD that's embedded in the beacon template command separately. Restore iwl_mvm_mac80211_idx_to_hwrate() to return only the rate index, not PLCP value, fixing the real TX_CMD.
Quoted source text, attributed separately from HOL analysis.