Microsoft's Security Response Center (MSRC) has listed a newly patched vulnerability in the Linux kernel that can crash devices using Microchip's External Interrupt Controller (EIC). The bug, tracked as CVE-2025-68766, stems from an out-of-bounds read flaw in the mchp-eic driver's interrupt domain translation code. A fix is already available in the mainline kernel, and Microsoft's advisory serves as a prompt for Windows users who manage Linux systems—from hobbyist single-board computers to enterprise hybrid cloud setups—to review their exposure.

The Vulnerability Explained

At the core of CVE-2025-68766 is a logic error in how the Microchip EIC driver handles interrupt specifiers from firmware or device trees. When the irq_domain_translate_twocell helper function produces a hardware interrupt number (hwirq) that falls outside the controller's supported range—specifically, greater than or equal to MCHP_EIC_NIRQ, which is a compile-time constant set to 2—the driver's allocation routine, mchp_eic_domain_alloc, correctly detects the invalid value but fails to return an error. As a result, the kernel proceeds with an out-of-bounds index, potentially reading memory it shouldn't and triggering a kernel oops or panic.

The upstream fix is minimal: the allocation function now returns -EINVAL when the hwirq is out of range, causing the kernel to reject the malformed mapping safely. This change alters only the error path, leaving normal operation untouched and making the patch easy to backport to stable kernel branches.

Who Is Affected?

While the vulnerability resides in a Linux kernel driver, Microsoft's interest—and the MSRC advisory—likely stems from its use of Linux in various products and services. Azure Sphere, certain IoT Edge devices, and the Azure Kubernetes Service all run Linux kernels, and even Windows Subsystem for Linux 2 (WSL2) ships with a Microsoft-tuned kernel. However, the specific driver (irq-mchp-eic) is only built for systems that include the Microchip EIC hardware, which is found in small system-on-chip (SoC) designs and embedded boards, not in typical cloud infrastructure or desktop WSL environments.

  • Everyday Windows users: Your laptop or desktop is almost certainly not vulnerable. The driver isn't loaded or used on standard x86 hardware, and WSL2 kernels are configured with a minimal set of drivers that exclude niche SoC peripherals.
  • Power users and hobbyists: If you run Linux on single-board computers (like those based on Microchip's SAMA5 or PIC32 family) or build custom kernels for embedded projects, you need to check your configuration. Any kernel that compiles the irq-mchp-eic driver is at risk until patched.
  • IT professionals and administrators: Those managing Linux VMs on Azure, Azure Sphere deployments, or IoT gateways that might incorporate Microchip SoCs should verify affected kernel versions and apply vendor updates. Microsoft's advisory signals that the company is tracking the issue for its own platforms, so expect coordinated guidance for any impacted Microsoft products.

How We Got Here

The irqchip/mchp-eic driver was introduced to support Microchip's external interrupt controller, commonly used in ARM-based SoCs for industrial and IoT applications. Like many kernel drivers, it relies on device-tree bindings to map hardware interrupts, a process that involves translating a two-cell specifier (a pair of numbers from firmware) into a hardware IRQ index. The irq_domain_translate_twocell function performs this mapping but can yield invalid values if the firmware data is malformed—either by a buggy device tree or a deliberate attack.

Security researchers or kernel maintainers discovered that the driver's error handling didn't cover all cases, leaving a gap where an invalid index could be used. The vulnerability was assigned CVE-2025-68766, and SUSE's initial assessment rated it as moderate severity with a local attack vector and high availability impact. The fix landed in the mainline kernel and was quickly backported to stable branches, with maintainers emphasizing the importance of defensive error returns in low-level IRQ code.

What You Should Do Now

Although direct risk to most Windows users is negligible, the advisory warrants a few concrete actions:

  1. Inventory your Linux systems. If you manage any Linux devices—whether under Azure, in WSL2, or as standalone servers—run uname -r to check the kernel version. Then, examine the kernel configuration (zcat /proc/config.gz or lsmod | grep eic) to see if the irq-mchp-eic module is present. On most x86 and common ARM64 systems, it won't be.
  2. Apply patches for affected systems. For embedded or development boards running kernels that include the driver, update to a fixed kernel. Distributions like Debian, Ubuntu, and SUSE will incorporate the patch in their security updates; consult your vendor's advisory. If you build your own kernels, cherry-pick the upstream commit that adds the -EINVAL return in mchp_eic_domain_alloc.
  3. For Microsoft-specific products: Keep an eye on the MSRC advisory page for any product-specific guidance. If you use Azure Sphere or Microsoft IoT Edge devices with custom Linux kernels, contact Microsoft Support to confirm whether a firmware update is needed. The advisory currently does not list any Microsoft products as directly affected, but that could change.
  4. Test and validate. After patching, reboot affected devices and verify that no kernel oops or crash occurs during boot or device probing. Logs can be checked with dmesg or journalctl -k.
  5. Mitigate if patching isn't immediate: If the hardware isn't using the EIC, blacklist the module by adding blacklist irq-mchp-eic to a file in /etc/modprobe.d/. Harden device-tree provisioning processes to prevent malformed interrupt specifiers from being deployed.

Outlook

The fix for CVE-2025-68766 is textbook kernel maintenance: a small, precise change that eliminates a dangerous edge case without altering normal behavior. As distributors roll out updates, the vulnerability will fade into the background for most users—but it highlights a persistent challenge in the embedded Linux ecosystem, where specialized drivers can harbor subtle bugs long after initial testing. For Windows-centric environments, the incident is a reminder that the boundary between Windows and Linux is porous: tools like WSL, Azure services, and IoT platforms blend OSes in ways that make cross-platform security awareness essential. Expect Microsoft to keep tracking such flaws and integrating relevant fixes into its own Linux-based offerings, even when the original bug is far from a Windows desktop.