CVE-2026-64176

What it actually does

This flaw affects the Linux kernel Intel iwlwifi MVM wireless driver on older Intel Wi-Fi devices such as the 7265D. The driver may encode transmit rates incorrectly when preparing TX_CMD structures, particularly after changes related to legacy v1, v2, and v3 rate formats and beacon-rate handling. Incorrect rate values can be sent to firmware, which may trigger driver warnings, firmware assertions, firmware crashes, or loss of wireless functionality. Because the issue is in kernel driver/firmware interaction, impact is primarily availability of Wi-Fi networking on affected systems; the provided CVSS vector also indicates adjacent-network reachability and high confidentiality impact, but the public description most clearly supports denial-of-service behavior.

Why it matters to the business

Affected laptops, workstations, embedded systems, or appliances using vulnerable Linux kernels with older Intel wireless chipsets may experience wireless instability, disconnections, or loss of network connectivity. In operational environments that rely on Wi-Fi for user productivity, point-of-sale, field devices, kiosks, or industrial endpoints, this can cause service disruption and support burden. The issue is not currently listed in CISA KEV, has low EPSS, and has no known public exploit maturity in the provided data, so broad internet-scale exploitation is unlikely; however, adjacent wireless attackers or hostile local radio environments may still be relevant for exposed devices.

How an attack unfolds

An attacker would need to be within wireless range of a vulnerable system using an affected Intel iwlwifi-supported device and a vulnerable Linux kernel. The attacker would attempt to influence Wi-Fi management or transmission behavior so the driver constructs or uses malformed or incompatible transmit-rate values for older firmware rate formats. When those values are processed by the wireless firmware, the device may assert, crash, or report invalid transmit command usage, causing Wi-Fi disruption until the driver or device recovers, the interface is reset, or the system is rebooted. There is no indication from the provided data that exploitation is being actively used by named threat actors or ransomware campaigns.

How to fix it

Upgrade to a Linux kernel version that includes the iwlwifi MVM fix for driver-set TX rates on older devices. Because no exact fixed package versions were provided, use the fixed kernel releases or vendor backports published by the relevant Linux distribution, hardware vendor, or appliance vendor. Prioritize systems with Intel iwlwifi-supported older wireless devices such as 7265D and systems that depend on Wi-Fi for critical connectivity. Where immediate patching is not possible, reduce exposure by disabling Wi-Fi on affected systems, using wired networking, disabling vulnerable wireless hardware, preventing association with untrusted access points, or restricting operation in untrusted wireless environments. Kernel module changes generally require rebooting into the fixed kernel or reloading the affected driver after installing updates.

How to confirm the fix worked

Confirm the running kernel contains the vendor fix by checking the installed kernel package changelog, distribution security advisory, or upstream commit history for the iwlwifi MVM rate-handling fix. Verify affected systems are no longer booted into older vulnerable kernels after patching. On representative hardware, test Wi-Fi association, beacon handling, reconnects, suspend/resume, and sustained traffic to confirm the interface remains stable and kernel logs no longer show iwlwifi firmware assertions or TX_CMD rate-related warnings. Inventory systems for Intel iwlwifi devices with commands such as lspci, lsmod, modinfo iwlwifi, and dmesg, then correlate with kernel versions to confirm exposure is removed.

Typical attack path

1. Identify Linux systems using Intel iwlwifi MVM wireless devices, especially older chipsets such as Intel 7265D.
2. Position within adjacent wireless range of the target system or operate a controlled access point/802.11 radio environment the target interacts with.
3. Trigger Wi-Fi behavior involving beacon or transmit-rate handling that causes the vulnerable driver to encode rates incorrectly for the firmware generation.
4. Cause the wireless firmware or driver to emit warnings, assert, crash, or reset.
5. Maintain disruption by repeatedly triggering the condition after interface recovery or reconnect attempts.

How to detect it

Look for evidence of repeated Intel wireless driver or firmware instability in kernel logs before patching. Useful sources include systemd journal entries for the kernel, /var/log/kern.log, /var/log/messages, /var/log/syslog, endpoint telemetry containing kernel ring buffer output, crash dumps, and wireless management logs from NetworkManager or wpa_supplicant. Search for iwlwifi firmware assertions, microcode error dumps, TX command warnings, device resets, interface down/up cycles, and repeated disconnect/reconnect events clustered around times when the endpoint was in Wi-Fi range. These artifacts are not proof of malicious exploitation because they can also occur from driver bugs, firmware issues, RF interference, or hardware problems; prioritize cases where many affected endpoints show similar iwlwifi crashes in the same physical area or while connected to the same access point. No named threat actors or ransomware campaigns were provided for this vulnerability.

• iwlwifi
• iwlmvm
• Microcode SW error detected
• Start IWL Error Log Dump
• FW assert
• firmware assert
• firmware crash
• FW error
• FW error in SYNC CMD
• TX_CMD
• beacon template
• iwl_mvm_mac80211_idx_to_hwrate
• Hardware error detected
• Queue stuck
• Failed to run INIT ucode
• Device error - SW reset
• wlan0: deauthenticating
• wlan0: disassociated
• NetworkManager.*iwlwifi
• kernel: iwlwifi

What your security team should do

• Inventory Linux endpoints and appliances using Intel iwlwifi wireless drivers, prioritizing older Intel wireless devices such as 7265D.
• Apply vendor-supported kernel updates that include the iwlwifi MVM TX-rate fix, and ensure systems reboot into the fixed kernel.
• For systems where Wi-Fi is not required, disable the wireless interface or block loading of the iwlwifi module as a compensating control.
• Monitor kernel logs for repeated iwlwifi firmware crashes, microcode error dumps, TX_CMD warnings, or Wi-Fi interface resets, especially in facilities with untrusted adjacent wireless presence.
• Treat repeated post-patch iwlwifi crashes as potential residual exposure, hardware/firmware incompatibility, or active adjacent triggering and escalate for endpoint forensics and wireless investigation.
• Because this is not KEV-listed and EPSS is low, schedule remediation according to exposure and business criticality, but prioritize mobile, kiosk, operational, and wireless-dependent systems.