CVE-2026-43172

What it actually does

This is an out-of-bounds array access in the Linux kernel iwlwifi driver for Intel 22000-series wireless devices. During firmware shared-memory configuration parsing, the driver could trust an invalid firmware-reported LMAC count of three and access fwrt->smem_cfg.lmac[2] even though the array does not contain that element. In a vulnerable kernel, a malformed or unexpected firmware/device state can therefore corrupt or disclose adjacent kernel memory, potentially causing kernel panic, privilege-impacting memory corruption, or broader compromise of kernel integrity depending on exploitability on a given platform.

Why it matters to the business

Systems using affected Linux kernels with Intel iwlwifi 22000-series wireless hardware may be exposed to a high-impact kernel memory corruption flaw that can affect confidentiality, integrity, and availability. The current public exploitation signal is low: EPSS is 0.00256 and flat over 30 days, it is not listed in CISA KEV, is not known to be used in ransomware campaigns, and no mature public exploit is indicated. Organizations should still prioritize remediation for laptops, workstations, embedded Linux systems, and wireless-enabled servers where Wi-Fi is enabled, especially because successful exploitation at kernel level can result in full system compromise or denial of service.

How an attack unfolds

An attacker would need a path to influence the iwlwifi firmware/driver interaction on a system using an affected kernel and relevant Intel wireless hardware. The vulnerable driver parses firmware-reported shared-memory data and fails to reject an impossible three-LMAC configuration. If the attacker can cause or supply such malformed firmware state, the kernel driver reads or writes outside the intended LMAC array boundary. That memory corruption may crash the kernel immediately or, with additional exploit development and platform-specific knowledge, be shaped into kernel-level code execution or information disclosure. Because the affected component is a kernel driver, exploitation impact is high, but practical exploitation appears constrained by hardware, driver state, and the need to reach the vulnerable parsing path; no public mature exploit or active exploitation is currently reported.

How to fix it

Upgrade affected Linux kernels to a vendor release that includes the upstream iwlwifi fix for rejecting invalid 22000-series SMEM LMAC counts. Because no exact fixed versions were provided, use the latest security-supported kernel packages from the relevant Linux distribution or hardware vendor and confirm the changelog references the iwlwifi 22000-series SMEM parsing fix. Where immediate patching is not possible, reduce exposure by disabling Wi-Fi on affected systems, unloading or blacklisting the iwlwifi module where operationally feasible, using wired networking, and preventing untrusted firmware updates or unsigned kernel/firmware components. Treat module blacklisting as a temporary mitigation because it may affect wireless connectivity and does not replace applying the kernel fix.

How to confirm the fix worked

Confirm the running kernel package is at or above the vendor-fixed build containing the iwlwifi SMEM parsing patch, not merely that an updated package is installed. Validate with kernel package inventory, uname -r, distribution security advisories, and module metadata for iwlwifi. On representative systems with Intel 22000-series adapters, verify Wi-Fi continues to operate after patching and that kernel logs no longer show warnings, crashes, or firmware parsing failures from iwlwifi during adapter initialization, suspend/resume, roaming, and reconnection. For mitigations, verify the iwlwifi module is not loaded with lsmod or equivalent tooling and that wireless interfaces are absent or administratively disabled.

Typical attack path

1. Identify a Linux system running an affected kernel with the iwlwifi driver and Intel 22000-series wireless hardware enabled.
2. Gain a way to influence the wireless firmware/driver state, such as through malformed firmware/device interaction or adjacent wireless-triggered driver behavior if reachable on the target platform.
3. Cause the firmware shared-memory configuration parser to receive an invalid LMAC count of three.
4. Trigger the vulnerable parsing path so the driver accesses fwrt->smem_cfg.lmac[2] out of bounds.
5. Leverage the resulting kernel memory corruption for denial of service, information disclosure, or potential kernel-level execution depending on system protections and exploit reliability.
6. Maintain access or disrupt operations if kernel compromise or repeated crashes are achieved.

How to detect it

To determine whether this was already exercised, review kernel and system logs from affected wireless-enabled Linux systems for iwlwifi driver crashes, warnings, firmware parsing errors, microcode failures, kernel oopses, or panics around Wi-Fi initialization, roaming, suspend/resume, or association events. Useful log sources include journald, /var/log/kern.log, /var/log/syslog, dmesg output, crash dump repositories, kdump/vmcore artifacts, EDR kernel-event telemetry, and fleet hardware inventory showing iwlwifi usage. Look for repeated iwlwifi failures immediately before unexpected reboots or kernel panics. There are no known public attacker-specific indicators, named threat actors, or stable network signatures for this issue; detections should focus on vulnerable-driver exposure and anomalous kernel/driver failure artifacts rather than definitive compromise indicators.

• iwlwifi
• Invalid number of LMACs
• Microcode SW error detected
• kernel: WARNING
• kernel BUG
• Oops:
• Kernel panic
• iwlwifi.*Microcode SW error detected
• iwlwifi.*Invalid number of LMACs
• iwlwifi.*WARNING
• /var/log/kern.log
• /var/log/syslog
• /var/crash
• /proc/modules

What your security team should do

• Prioritize patching Linux laptops, workstations, and embedded systems that use Intel iwlwifi 22000-series wireless hardware.
• Inventory systems where the iwlwifi kernel module is loaded and correlate with kernel versions to identify exposure.
• Apply the latest vendor-supported kernel security updates and reboot systems to ensure the fixed kernel is running.
• If patching is delayed, temporarily disable Wi-Fi or blacklist the iwlwifi module on systems where wireless connectivity is not required.
• Monitor kernel logs for iwlwifi warnings, firmware parsing failures, microcode errors, oopses, and panics that could indicate attempts to reach the vulnerable path or related instability.
• Because EPSS is low, flat, and there is no KEV or known ransomware use, schedule remediation according to normal high-severity kernel patch SLAs unless the system is highly exposed or business-critical.
• Ensure Secure Boot, signed kernel modules, and firmware integrity controls are enabled where available to reduce the chance of malicious firmware or driver tampering.