Microsoft recently flagged CVE-2025-23140, a vulnerability in the Linux kernel’s PCI endpoint test driver, as affecting Azure Linux. But the security community quickly noticed a critical nuance: the advisory’s wording could be misread as suggesting that only Azure Linux is impacted. That’s not the case. The same buggy code can quietly reside in other Microsoft-supplied artifacts—including Windows Subsystem for Linux 2 (WSL2) kernels and Azure Marketplace images—and admins who stop at patching only their Azure Linux instances may leave a gaping hole.

What actually changed

On its CVE page, the Microsoft Security Response Center (MSRC) stated that CVE-2025-23140 affects Azure Linux because the distribution “includes this open-source library” and is therefore “potentially affected.” The advisory didn’t say “only” or “exclusively.” Instead, it reflects Microsoft’s new rollout of machine-readable Vulnerability Exploitability eXchange (VEX) attestations, which began with Azure Linux as a pilot product family. The company has committed to expanding these attestations to other products if and when inventory checks reveal they include the same upstream component.

The bug itself sits in the kernel’s PCI endpoint test driver (pci_endpoint_test). When an interrupt request fails during initialization, the error path mishandles cleanup—some IRQs stay registered, leaving stale entries under /proc/irq and triggering kernel warnings like “remove_proc_entry: removing non-empty directory ‘irq/30’”. While not a remote-code-execution threat, it can cause resource leaks, log noise, and availability issues on systems where the driver is loaded. The upstream fix adjusts bookkeeping to release remaining IRQs before cleanup, and most major distributions have already shipped patched kernels.

What it means for you

For home users running standard Windows with WSL2, the exposure depends on the kernel version shipped with your WSL2 install. Microsoft’s WSL2 kernel sources are separate from Azure Linux, and the company hasn’t yet published a VEX attestation for WSL2. That means silence from MSRC is not safety—you need to check manually. Developers using custom Azure Linux or other Microsoft-authored images for CI/CD may find the test driver compiled into kernels they assumed were clean.

Enterprise admins face a larger headache. If you manage Azure Linux virtual machines, the MSRC guidance is clear: patch immediately per Microsoft’s Azure Linux update channel. But if your environment also contains Azure Marketplace appliances, container host images, or device firmware that Microsoft distributes, you can’t simply assume they’re in the clear. The pci_endpoint_test driver can be built either as a kernel module (.ko) or statically into the kernel image itself—so even if lsmod doesn’t show it, the vulnerable code may still be present.

How we got here

CVE-2025-23140 is a classic kernel robustness flaw, assigned a CVSS 3.1 base score of 5.5 (medium) because exploitation requires local access. It was disclosed and fixed upstream months ago; distributors like Ubuntu, Debian, and SUSE published their own advisories and patches long before Microsoft’s statement. So why did Microsoft’s advisory cause confusion now?

The answer lies in Microsoft’s evolving transparency efforts. In October 2025, the company announced it would begin publishing VEX attestations for third-party CVEs, starting with Azure Linux. The goal is to reduce false positives for security scanners and give customers clear, machine-readable exploitability statuses: Not Affected, Under Investigation, Known Affected, or Fixed. For CVE-2025-23140, Azure Linux falls into “Known Affected.” But because the rollout is incremental, other Microsoft products that might embed the same upstream code haven’t been inventoried yet. Their status is effectively “Under Investigation” until MSRC updates the CVE page.

This isn’t unusual. Many large organizations ship multiple kernel builds that independently pull in the same open‑source component. A WSL2 kernel, an Azure Sphere image, or a custom IoT appliance might all carry CONFIG_PCI_ENDPOINT_TEST=y without anyone realizing it. Microsoft’s silence on those products isn’t a declaration of safety; it’s a side effect of a phased disclosure program.

What to do now

1. Patch Azure Linux immediately

If you run Azure Linux, check Microsoft’s VEX/CSAF entry for CVE-2025-23140 and apply the recommended kernel update. The company’s attestation is authoritative for Azure Linux objects, and delaying gives attackers a local vector for resource exhaustion.

2. Inventory every Microsoft-supplied kernel artifact

Don’t stop at Azure Linux. For each image, VM, or appliance you run—especially WSL2 kernels, Azure Marketplace items, and embedded devices—perform these checks:

  • Look for the device node: ls /dev | grep pci-endpoint-test
  • Check kernel modules: lsmod | grep -E 'pci(_|-)?endpoint'
  • Inspect kernel configuration:
    bash grep CONFIG_PCI_ENDPOINT_TEST /boot/config-$(uname -r) # or zcat /proc/config.gz | grep CONFIG_PCI_ENDPOINT_TEST
    If the output is =y, the driver is built into the kernel image. If =m, it’s a loadable module.
  • Scan /proc/irq for remnants: grep -R "pci-endpoint-test" /proc/irq (presence indicates the driver loaded).

3. Mitigate if you can’t patch right away

  • Blacklist the module: Create /etc/modprobe.d/blacklist-pci-endpoint-test.conf with blacklist pci_endpoint_test. Then unload it if safe: sudo modprobe -r pci_endpoint_test.
  • Rebuild custom images with CONFIG_PCI_ENDPOINT_TEST=n to remove the driver entirely from production builds.

4. Handle WSL2 with care

WSL2 kernels are managed by Microsoft, but your local version may differ. Check the kernel version with uname -r inside WSL, then compare against the latest WSL2 kernel release notes. If you’re unsure, blacklist the module as above. Remember that WSL2 shares the kernel across all running distributions, so a vulnerable kernel affects every WSL2 instance on that machine.

5. Update your vulnerability scanners

Feed MSRC’s VEX/CSAF data into your scanning tools. For Azure Linux, the VEX file already provides a trustworthy “Affected” or “Fixed” status. For other Microsoft products, mark them as “Needs Verification” until MSRC publishes an update or you complete manual checks.

Outlook

The CVE-2025-23140 episode underscores a maturing but incomplete supply-chain transparency model. Microsoft’s move to VEX is a genuine improvement: it replaces vague statements with structured, auditable data. But until the attestations reach beyond Azure Linux, the burden remains on defenders to connect the dots. Watch for MSRC updates on this CVE—Microsoft has committed to expanding VEX coverage, and future statements may finally clear the fog over WSL2, Azure Marketplace, and other artifacts. In the meantime, verify, don’t assume.