Microsoft’s May 6, 2026 vulnerability disclosures contained an entry that will confuse any administrator who only associates Redmond with Windows: CVE-2026-43172, an out-of-bounds array access in the Linux kernel’s iwlwifi driver. The bug, which affects Intel 22000-series wireless hardware, was fixed upstream in kernel stable trees months ago—but its appearance in Microsoft’s Security Update Guide exposes the increasingly tangled reality of cross-platform security.

No, this is not a Windows wireless vulnerability. It is, however, a concrete reason to check whether your Linux laptops, developer VMs, and WSL environments are running a kernel from before late February 2026.

What Actually Changed: A Failing Bounds Check in Firmware Parsing

The iwlwifi driver handles Intel Wi-Fi cards on Linux, and part of its initialization involves reading a shared-memory configuration table provided by the device firmware. For the 22000 series, that table includes a count of logical MAC units (LMACs). The driver’s parser contained an assumption: firmware would never report three LMACs on hardware that physically has only two.

An assumption, as it turned out, without a guardrail. If a malformed firmware image supplied the impossible value, the driver would index beyond the end of the smem_cfg.lmac array. The fix, committed to the Linux kernel’s netdev tree and backported through stable channels in late February 2026, is blunt: the driver now validates the firmware-reported LMAC count against the actual array size before using it, and also hardens an additional size check for shared-memory notifications.

The changed file is drivers/net/wireless/intel/iwlwifi/fw/smem.c, and the diff is tiny—fewer than a dozen lines. It swaps a lenient, warning-based approach for a hard check that treats the firmware as potentially hostile.

What It Means for You

If You Run Linux

On most distributions, the patch cycle has already delivered the fix to current kernels. Ubuntu 24.04 with the HWE edge kernel, Fedora 41, Arch, and openSUSE Tumbleweed are almost certainly immune if you installed routine updates after March 2026. However, Long-Term Support (LTS) kernels, embedded images, and custom appliance builds may lag.

Check your kernel version. The upstream fix landed in 6.2-rc and was backported to 6.1.y, 5.15.y, and 5.10.y stable branches. If you boot a kernel older than 5.10.174 (or the equivalent backport from your vendor), you probably have the vulnerable code.

If You Run Windows

The vulnerability does not reside in the Windows networking stack. The Windows Wi-Fi driver for Intel adapters is a separate codebase and is not affected. However, if you use the Windows Subsystem for Linux (WSL2) with its own kernel, that kernel is a Microsoft-maintained Linux kernel and receives updates through Windows Update. Check your WSL kernel version with uname -r inside a WSL terminal. The latest WSL kernel as of May 2026 should contain the fix.

If You Manage a Mixed Environment

Your biggest risk is neglect. Linux machines used by developers, QA labs, or home-lab enthusiasts often sit behind corporate update policies. The fact that Microsoft publicized this CVE is a reminder that vulnerability feeds are now cross-platform by default. If your team only scans for Windows CVEs and ignores advisories tagged with “Linux,” CVE-2026-43172 will slip through.

How We Got Here: The Expanding Attack Surface of Firmware

This bug is not the result of a single programmer’s slip; it’s the product of a decade-long trend in which driver code has become a security boundary between the OS and opaque device firmware. The iwlwifi driver, loaded by default on millions of devices, must negotiate with a binary blob that defines memory regions, FIFOs, and capabilities. A mistake in that negotiation—trusting a value that hardware reality should make impossible—is exactly the kind of flaw that keeps compiler sanitizers and fuzz campaigns busy.

Microsoft’s decision to include the CVE in its own guide is not a claim of ownership. It’s an acknowledgement that Microsoft now ships, supports, and secures a broad Linux estate: Azure cloud images, WSL, container infrastructure, and products that pull in open-source components. Windows administrators may discover Linux vulnerabilities through the same portal they use for Patch Tuesday, but remediation still lives in the world of apt, dnf, and pacman.

What to Do Now

  1. Inventory your Linux footprint. Identify all Linux desktops, laptops, VMs, and appliances with Intel Wi-Fi hardware. The iwlwifi driver supports Intel Wireless-AC 22000 series adapters, commonly found in laptops and mini PCs from Dell, Lenovo, Framework, and Intel NUCs.
  2. Check kernel versions. On each Linux system, run uname -r. If the version is less than 5.10.174, 5.15.73, or 6.1.19 (or your distribution’s equivalent backport), it is likely vulnerable.
  3. Install updates and reboot. Apply the latest kernel package from your distribution’s repository and reboot into the new kernel. Merely installing the update is not enough—the running kernel does not change until you restart.
  4. Verify the booted kernel. After reboot, confirm the new kernel version with uname -r and dmesg | grep iwlwifi to ensure the driver loaded without errors.
  5. Update WSL if used. For WSL2 users, run wsl --update from an elevated Windows terminal, then restart your WSL instance.
  6. Don’t panic. As of May 6, 2026, there is no public exploit code and no indication the bug is being used in the wild. The fix predates the CVE by months, so most actively maintained systems are already protected.

Outlook

The NVD has not yet assigned a CVSS score to CVE-2026-43172, but the absence of a score should not delay patching. Kernel memory-safety bugs are always serious, even when the path to exploitation is narrow. The real test will come when attackers find ways to manufacture the “impossible” states that the driver now rejects. For now, treat this as a low-drama, high-discipline opportunity to verify that your Linux kernel update pipeline actually works.