Look up another CVE · open CVE-2026-64176 in the interactive tracker
CVE-2026-64176
wifi: iwlwifi: mvm: fix driver-set TX rates on old devices
Published 2026-07-19 (3 months ago) by the Linux kernel CNA. Subsystem drivers/net. Debian urgency: unimportant.
Debian does not build this code. The per-release build detail is under "Where it lives" below.
What to do, per Debian release
Debian's own status for CVE-2026-64176 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | not affected | 6.1.190-1 | Nothing to do. bookworm never shipped the vulnerable code. |
| Debian 13trixie | not affected | 6.12.113-1 | Nothing to do. trixie never shipped the vulnerable code. |
| Debian 14forky | fixed | 7.0.12-1 | Update the kernel and reboot. Fixed in 7.0.12-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.0.12-1 | Update the kernel and reboot. Fixed in 7.0.12-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
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.
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c
drivers/net/wireless/intel/iwlwifi/mvm/utils.c
- What this is
- INTEL WIRELESS WIFI LINK (iwlwifi)MAINTAINERS section matched on drivers/net/wireless/intel/iwlwifi/ · linux-wireless@vger.kernel.org · Supported
- Kernel module
- none to look for. The file would have gone into iwlmvm, and Debian does not compile it into that module, so finding iwlmvm in lsmod would say nothing about this CVE.
Check it on the machine
grep -wE 'CONFIG_IWLMEI|CONFIG_IWLMVM|CONFIG_IWLWIFI|CONFIG_WLAN|CONFIG_WLAN_VENDOR_INTEL' /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
Show whether Debian builds this, per release
Debian does not build this code. In 4 releases below, every kernel flavour Debian publishes has the switch off, so the vulnerable file is compiled into no kernel binary Debian ships.
- bookworm, trixie, forky, sidn
- n
- not enabled on any flavour - this release does not build the code
- Build switches
- CONFIG_IWLMEI, CONFIG_IWLMVM, CONFIG_IWLWIFI, CONFIG_WLAN, CONFIG_WLAN_VENDOR_INTEL
- Reads as
- all on means the file is compiled; any one off means it is not.
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-07-19 (3 months ago)source
- CVSS
- 8.1 high
CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:Hsource recompute it - Attack vector
- adjacent network (AV:A)source
- EPSS
- 0.21%, higher than 10.4% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- unimportantsource
- Subsystem
- drivers/net
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 6.18 | 6.18.34 | 6fe92651b44f |
| 6.18 | 7.0.11 | 6b58a79f2cd9 |
| 6.18 | 7.1 | fb84b5cbcaab |
| 6.17.9 | 0 | 0 |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:AAttack vector, adjacent network
- The vulnerable TX rate path is reached when the iwlwifi driver transmits WiFi management frames (probe responses, auth/assoc) or beacon templates in response to over-the-air activity. A remote attacker on the same WiFi/BSS segment can trigger this by sending probe requests to a victim AP or operating a rogue AP that causes victim clients to exchange management frames.
- AC:LAttack complexity, low
- Once the victim uses affected legacy Intel hardware (e.g. 7265D with v1 rate firmware), the attacker can reliably trigger the bug by sending standard 802.11 management frames; no special timing, memory layout, or race conditions beyond normal WiFi traffic are required.
- PR:NPrivileges required, none
- An adjacent attacker needs no privileges on the victim system. Exploitation is triggered purely by WiFi frames received by the victim's wireless interface; no local account, CAP_NET_ADMIN, or ioctl/netlink access on the victim is required.
- UI:NUser interaction, none
- From the attacker's perspective, no action by the victim user is needed beyond the WiFi interface being active (e.g., an AP broadcasting beacons or a client performing normal association). Probe responses and association handshakes are sent automatically by the driver.
- S:UScope, unchanged
- The vulnerability is confined to the iwlwifi kernel driver and its firmware interaction on the victim host. Impact does not cross a security boundary such as VM escape, sandbox escape, or IOMMU bypass.
- C:HConfidentiality impact, high
- The double PLCP conversion passes PLCP values (e.g. 55, 110 for CCK rates) as array indices to iwl_fw_rate_idx_to_plcp(), which performs an unchecked lookup into a ~17-element table, causing out-of-bounds kernel memory reads whose results are embedded into TX commands.
- I:NIntegrity impact, none
- The bug corrupts rate-encoding metadata sent to firmware but does not provide an arbitrary kernel write, use-after-free, or demonstrated control-flow hijack primitive. Impact is malformed TX parameters and firmware misbehavior, not integrity of arbitrary kernel or user data.
- A:HAvailability impact, high
- The fix commit and prior bug report document firmware assert/crash from incorrect beacon/TX_CMD rates on old devices, and the RX path emits WARN_ON for invalid rate values reported back from firmware. This can disable WiFi connectivity and potentially cause repeated firmware restart loops.