CVE-2026-43325

What it actually does

CVE-2026-43325 is a local denial-of-service flaw in the Linux kernel iwlwifi MVM driver. On some Intel Wi-Fi devices such as AX201, firmware may incorrectly advertise support for the 6 GHz/6E-related MCC_ALLOWED_AP_TYPE_CMD command even though the hardware does not support 6E. Vulnerable kernel code trusts that advertised capability and sends the unsupported command, causing the Wi-Fi firmware to crash. The primary technical effect is loss of Wi-Fi functionality and related network availability until the device, driver, firmware, or host is reset/reinitialized. The CVSS vector indicates local access with low complexity and low privileges is required, with no confidentiality or integrity impact but high availability impact.

Why it matters to the business

Successful exploitation can disrupt wireless connectivity on affected Linux systems, causing user downtime, interrupted remote access, failed network-dependent workloads, and operational disruption for laptops, workstations, kiosks, edge systems, or other devices that rely on Intel iwlwifi wireless networking. Because this is not listed in CISA KEV, has very low EPSS, and has no known public exploit maturity in the provided data, broad internet-scale exploitation is unlikely; however, organizations with large Linux laptop or wireless edge fleets may still see support impact if unpatched systems encounter the firmware crash condition.

How an attack unfolds

An attacker must already have local, low-privileged access to a vulnerable Linux system using an affected Intel iwlwifi device/firmware combination. The attacker triggers kernel behavior that causes the iwlwifi MVM driver to evaluate device capabilities and send the 6E-related MCC_ALLOWED_AP_TYPE_CMD command despite the device not actually supporting 6E. Because the firmware incorrectly advertises the command as supported, the vulnerable driver sends it, and the firmware crashes. The result is a denial of service against the wireless adapter rather than code execution, data theft, or privilege escalation. Recovery typically requires restarting the wireless stack, reloading the driver, resetting the device, or rebooting the system.

How to fix it

Update the Linux kernel to a vendor release that includes the upstream iwlwifi MVM fix preventing MCC_ALLOWED_AP_TYPE_CMD from being sent when the device does not support 6E. Because no exact fixed versions were provided, use the relevant distribution security advisory or kernel changelog for the deployed Linux distribution and ensure the installed kernel contains the patch for 'wifi: iwlwifi: mvm: don\'t send a 6E related command when not supported.' Also apply available linux-firmware and Intel wireless firmware updates from the operating system vendor. If immediate patching is not possible, mitigations include disabling affected Wi-Fi hardware where operationally acceptable, using wired networking, restricting local shell access to trusted users, and monitoring/restarting affected wireless services after crashes.

How to confirm the fix worked

Confirm exposure by identifying systems using the iwlwifi driver and affected Intel wireless hardware, then checking whether the running kernel includes the iwlwifi MVM fix. Commands commonly useful for validation include checking loaded modules with 'lsmod | grep iwlwifi', device identity with 'lspci -nn | grep -i network', firmware messages with 'dmesg | grep -i iwlwifi', and package/kernel versions with the distribution package manager. Confirm remediation by booting into the patched kernel, verifying iwlwifi loads normally, and reviewing kernel logs to ensure there are no repeated firmware crashes or MCC_ALLOWED_AP_TYPE_CMD-related failures during Wi-Fi initialization, roaming, regulatory-domain changes, or hotspot/AP-mode operations.

Typical attack path

1. Obtain local low-privileged access to a Linux system using an affected iwlwifi-supported Intel wireless adapter such as AX201.
2. Confirm the system is running a vulnerable kernel/iwlwifi driver and an affected firmware/device capability combination.
3. Trigger wireless regulatory/capability handling that leads the driver to issue the 6E-related MCC_ALLOWED_AP_TYPE_CMD command.
4. The unsupported command is sent to firmware that incorrectly advertised support for it.
5. The Wi-Fi firmware crashes, disrupting wireless connectivity and causing a local availability impact.
6. Maintain or repeat the disruption by re-triggering the condition after the wireless device or host recovers.

How to detect it

To assess prior exploitation or occurrence, review Linux kernel logs, persistent journal logs, endpoint telemetry, and wireless service logs for iwlwifi firmware crashes, device resets, command failures, and Wi-Fi disconnects around times of user activity or local process execution. Relevant sources include 'dmesg', 'journalctl -k', '/var/log/kern.log', '/var/log/syslog', '/var/log/messages', NetworkManager logs, systemd-journald, EDR process telemetry, and audit logs for local user sessions. Look for repeated iwlwifi firmware crash messages, microcode/SYSASSERT dumps, hardware restart messages, and wireless interface down/up cycles. Because this vulnerability produces a denial-of-service condition and not a durable compromise artifact, evidence may be limited to transient kernel/firmware logs and recurring wireless resets. Correlate crash timestamps with local logins, suspicious scripts, NetworkManager/nmcli/iw commands, regulatory-domain changes, AP/hotspot mode attempts, or repeated attempts to manipulate wireless settings. There are no known threat actors or public exploit campaigns in the provided data.

• iwlwifi
• Microcode SW error detected
• Start IWL Error Log Dump
• Loaded firmware version
• Firmware error during reconfiguration
• FW error in SYNC CMD
• Failed to send MCC_ALLOWED_AP_TYPE_CMD
• MCC_ALLOWED_AP_TYPE_CMD
• Hardware restart was requested
• iwlwifi.*firmware.*crash
• iwlwifi.*Microcode SW error
• iwlwifi.*Failed to run INIT ucode
• iwlwifi.*Failed to start RT ucode
• iwlwifi.*Queue.*stuck
• wlan0: deauthenticating
• NetworkManager.*device.*disconnected
• /var/log/kern.log
• /var/log/syslog
• /var/log/messages

What your security team should do

• Inventory Linux endpoints and edge devices using Intel iwlwifi wireless adapters, especially AX201-class devices.
• Prioritize kernel updates for systems that depend on Wi-Fi for business-critical connectivity or remote administration.
• Apply both kernel and linux-firmware updates from the operating system vendor, then reboot into the patched kernel.
• Where patching is delayed, reduce risk by limiting local user access and using wired networking for critical systems where feasible.
• Create monitoring for repeated iwlwifi firmware crashes, wireless device resets, and sudden Wi-Fi connectivity loss on Linux fleets.
• Helpdesk and endpoint teams should treat recurring AX201/iwlwifi firmware crashes as a patch-validation and driver/firmware currency issue, not only as a hardware failure.
• Because there is no KEV listing, no ransomware association, very low EPSS, and no known exploit maturity in the provided data, prioritize based on operational exposure rather than emergency internet-facing risk.