CVE-2026-64175 wifi: iwlwifi: mld: stop TX during firmware restart
A missing check in the iwlwifi driver causes a tight loop during firmware crashes, leading to CPU exhaustion and memory pressure under high network traffic.
- Exploited in the wild
- Not known
- Login needed
- Not needed
- Attackable
- Over the internet
- Victim action needed
- Not needed
- Fix
- Available
What is CVE-2026-64175?
CVE-2026-64175 is a high-severity denial of service vulnerability in Linux kernel, published on 19 Jul 2026. An attacker can exploit it over the internet without logging in, with no action from the victim.
Official description
In the Linux kernel, the following vulnerability has been resolved:
wifi: iwlwifi: mld: stop TX during firmware restart
When iwlwifi firmware crashes (e.g., NMI_INTERRUPT_UNKNOWN on Intel BE201/Wi-Fi 7), iwl_mld_nic_error() sets mld->fw_status.in_hw_restart to true. However, iwl_mld_tx_from_txq() does not check this flag before dequeuing frames from mac80211 and pushing them to the transport layer.
Since the firmware is dead, iwl_trans_tx() returns -EIO for each frame, which then gets freed immediately. Under high-throughput conditions (e.g., Tailscale UDP traffic or active SSH sessions), this creates a tight dequeue-send-fail-free loop that wastes CPU cycles and generates rapid skb allocation churn, leading to memory pressure from slab fragmentation.
The RX path already has this guard (iwl_mld_rx_mpdu checks in_hw_restart at rx.c:1906), and so does the TXQ allocation worker (iwl_mld_add_txqs_wk at tx.c:156). Add the same guard to iwl_mld_tx_from_txq() to stop all TX during firmware restart.
Frames left in mac80211's TXQs are naturally drained after restart completes, when queue reallocation triggers iwl_mld_tx_from_txq() via iwl_mld_add_txq_list(), or when new upper-layer traffic invokes wake_tx_queue.
Tested on ASUS Zenbook 14 UX3405CA with Intel BE201 (Wi-Fi 7) on kernel 6.19.5 where the firmware crashes approximately every 10-15 minutes under Tailscale traffic.
Weakness: CWE-400
Which versions are affected by CVE-2026-64175?
It affects 1 product.
Products include Linux kernel.
How do I fix CVE-2026-64175?
Apply the vendor's patch.
Upgrade, then put limits on request size, rate and nesting depth so one client cannot exhaust the service. More about Denial of service.
Is CVE-2026-64175 being exploited?
There is no known exploitation of CVE-2026-64175 in the wild and no public exploit code.
Other vulnerabilities in Linux kernel
Sources
Also known as BELL-CVE-2026-64175, DEBIAN-CVE-2026-64175, GHSA-6wqh-xprc-m65r, UBUNTU-CVE-2026-64175.