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
Why It Matters
Analysis dossierWhy It Matters
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.
High
Unknown
Unknown
Risk basis: SOC ecosystem technology relevance; HIGH severity; No confirmed exploitation signal in current enrichment
Affected Products & Remediation
1 source-backed product- linux linux kernel · >= 6.15 < 6.18.34; >= 6.19 < 7.0.11; 7.1 · NVD CPE · Source
Vendor or catalog guidance (source)
Not provided by source
Known exploitation (source facts)
Only what a source states. Unknown means no source has said either way; it is not "not exploited".
- CISA KEV
- Unknown
- Exploited (source statement)
- Unknown
- Publicly disclosed (source)
- Unknown
Suggested hunting (rule-based inference)
SecOps Signal recommendation (rule-based inference). These steps are hunting hypotheses from the vulnerability class; they do not state or imply that exploitation occurred here or anywhere.
Matched network-unauthenticated (CVSS AV:N, CVSS PR:N, CVSS UI:N)
Exposure
- Identify devices reporting this CVE and note which expose the affected service to untrusted networks.Telemetry: DeviceTvmSoftwareVulnerabilities · A network-reachable, no-privilege vector makes internet-facing instances the first exposure question. · Rule network-unauthenticated
Exploitation evidence
- Review inbound connections to the affected service from unexpected sources since the advisory date.Telemetry: DeviceNetworkEvents · Hunting hypothesis from the CVSS vector; it does not show that exploitation occurred. · Rule network-unauthenticated
Response
- Confirm the source-stated update is installed and the CVE is no longer reported.Telemetry: DeviceTvmSoftwareVulnerabilities · A follow-up inventory check verifies remediation. · Rule network-unauthenticated
CISA KEV Record
CISA KEV status was not determined for this record.
Change History & Source Data
— No recorded material change
- CNA / source
- 416baaa9-dc9f-4396-8d5f-8c081fb06d67
- Record status · verification
- UPDATED · NVD API
- CPE
- cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*, cpe:2.3:o:linux:linux_kernel:7.1:rc1:*:*:*:*:*:*, cpe:2.3:o:linux:linux_kernel:7.1:rc2:*:*:*:*:*:*, cpe:2.3:o:linux:linux_kernel:7.1:rc3:*:*:*:*:*:*, cpe:2.3:o:linux:linux_kernel:7.1:rc4:*:*:*:*:*:*
Evidence & Provenance
— No published hunting query names this record. Browse community and library queries instead.
Correlated briefings
— No published briefing references this CVE