Microsoft’s short answer: No — Azure Linux is not necessarily the only Microsoft product that could include the vulnerable pci_endpoint_test component, but it is the only Microsoft product Microsoft has publicly attested so far as including that upstream code and therefore “potentially affected.”
CVE-2025-23140 is a Linux-kernel robustness bug in the PCI endpoint test driver (the misc driver that creates /dev/pci-endpoint-test.). The defect occurs when devm_request_irq() fails inside the pci_endpoint_test request path: the error path calls pci_endpoint_test_free_irq_vectors() while some IRQs remain registered, leaving stale entries under /proc/irq and triggering WARNs such as “remove_proc_entry: removing non-empty directory 'irq/30'”, effectively leaking the pci-endpoint-test device entry. The upstream remedy adjusts bookkeeping and releases remaining IRQs earlier so cleanup is correct.
Security scanners and distributors have assigned this issue a medium* base rating (CVSS v3.1 = 5.5) because exploitation requires local access and the impact is primarily availability/resource leakage rather than remote code execution. Vendors and distributions (Ubuntu, Debian, SUSE and others) have cataloged the CVE and published patches or kernel updates.
At the same time, Microsoft’s public CVE guidance language — which you quoted — has been repeatedly used in MSRC advisories to indicate inventory scope for third‑party (open‑source) components. Microsoft’s phrasing typically reads that “Azure Linux includes this open‑source lib potentially affected by this vulnerability,” and the company has said it will expand its machine‑readable attestations (CSAF/VEX) if more Microsoft products are later found to ship the same upstream component. That is a product‑scoped inventory attestation, not an exclusivity guarantee. ([microsoft.com](Toward greater transparency: Introducing Machine-readable Vulnerability Exploitability Xchange (VEX) for Azure Linux and beyond---
Source: MSRC Security Update Guide - Microsoft Security Response Center
Background / Overview
CVE-2025-23140 is a Linux-kernel robustness bug in the PCI endpoint test driver (the misc driver that creates /dev/pci-endpoint-test.). The defect occurs when devm_request_irq() fails inside the pci_endpoint_test request path: the error path calls pci_endpoint_test_free_irq_vectors() while some IRQs remain registered, leaving stale entries under /proc/irq and triggering WARNs such as “remove_proc_entry: removing non-empty directory 'irq/30'”, effectively leaking the pci-endpoint-test device entry. The upstream remedy adjusts bookkeeping and releases remaining IRQs earlier so cleanup is correct.Security scanners and distributors have assigned this issue a medium* base rating (CVSS v3.1 = 5.5) because exploitation requires local access and the impact is primarily availability/resource leakage rather than remote code execution. Vendors and distributions (Ubuntu, Debian, SUSE and others) have cataloged the CVE and published patches or kernel updates.
At the same time, Microsoft’s public CVE guidance language — which you quoted — has been repeatedly used in MSRC advisories to indicate inventory scope for third‑party (open‑source) components. Microsoft’s phrasing typically reads that “Azure Linux includes this open‑source lib potentially affected by this vulnerability,” and the company has said it will expand its machine‑readable attestations (CSAF/VEX) if more Microsoft products are later found to ship the same upstream component. That is a product‑scoped inventory attestation, not an exclusivity guarantee. ([microsoft.com](Toward greater transparency: Introducing Machine-readable Vulnerability Exploitability Xchange (VEX) for Azure Linux and beyond---
What Microsoft’s statement actually means — unpacking the wording
Azure Linux = attested; not necessarily exclusive
- When MSRC says “Azure Linux includes this open‑source library and is therefore potentially affected,” it is reporting the result of an inventory check that Microsoft performed for the Azure Linux distribution. That attestation is authoritative for Azure Linux objects (images, kernels, packages) that were inspected.
- However, the statement does not assert that Microsoft audited every Microsoft product, kernel image, Marketplace VM, WSL2 kernel build, or Azure service image. The absence of a similar attestation for another Microsoft product is absence of attestation, not proof of absence. Treat un‑attested artifacts as “unverified” until either Microsoft publishes a VEX/CSAF mapping for them or you verify those artifacts yourself.
Why Microsoft singled out Azure Linux first
- Microsoft publicly committed to publishing machine‑ attestations for Azure Linux as an initial rollout of improved supply‑chain transparency. That program began in October 2025 and means Microsoft will enumerate, per CVE, which of its product families include the implicated open‑source components. For now, Azure Linux is the initial product family Microsoft has inventory‑checked and published for many kernel CVEs.
- Because Azure Linux is the distro Microsoft maintains and updates for cloud customers, documenting its exposure is operationally valuable — but it is not a proxy for “no other Microsoft product is affected.”
Technical impact and risk profile
What the bug does (concise)
- The bug is a cleanup/logic error in the pci_endpoint_test misc driver: if devm_request_irq() fails while registering some interrupt vectors, the code assumes all IRQs were released and proceeds to free vectors; in reality, some IRQs remain registered and /proc/irq entries can stay behind. That leaves kernel WARNs and resource residue; the fix ensures the driver tracks the remaining IRQs correctly and releases them before cleanup.
Likely attacker model and impact
- Attack vector: local (an unprivileged or low‑privileged local user that can cause or trigger the test driver to run). CVSS and vendor notes reflect this locald.nist.gov]
- Practical impact: kernel WARNs, leftover /proc/irq entries, potential resource leakage, and in some circumstances availability problems if the leak accumulates. The issue is not a remote RCE or privilege escalation by itself.
Why this matters operationally
- Even “low-severity” kernel robustness issues can cause noisy logs, automated monitor alerts, churn in
/proc, or instability of test harnesses and automation that enumerates IRQs. - In multi‑tenant or large‑scale systems where many kernels and images are deployed (cloud hosts, appliance images, Marketplace VMs, WSL kernels), one unpatched artifact can become a recurrent operational problem if automation binds the test driver or image. That’s why inventory and artifact-level verification matter.
Cross‑checking the claim about affected Microsoft products
I validated the core CVE details and the Microsoft wording against sources:- National Vulnerability Database (NVD) provides the CVE description and technical summary confirming the pci_endpoint_test request_irq cleanup bug.
- Major distributions and vendor advisories (Ubuntu, Debian, SUSE, Oracle, and others) list CVE-2025-23140 and have distributed kernel patches or updates; these vendor pages confirm the fix and the practical remediation path (kernel updates).
- Microsoft’s public transparency blog and MSRC guidance describe the VEX/CSAF rollout and show the same attestation approach — Azure Linux is the first product family to receive machine‑readable VEX attestations and Microsoft will update CVE pages when other Microsoft products are identified as carriers of a given upstream component. That precisely matches the FAQ text that appears in Microsoft CVE entries you quoted.
Practical steps for defenders — How to determine whether you are affected
If you operate Microsoft artifacts (Azure Marketplace images, managed Azure Linux images, WSL kernels, Azure IoT/embedded images, Marketplace appliances, or any Microsoft‑distributed kernel artifacts), perform these checks for each artifact and image you run.1. Confirm the CVE is present in your kernel build
- Check the kernel package and version against vendor advisories (distributions publish which kernel versions incorporate the upstream fix). Prioritize nodes with kernel versions earlier than the patched versions noted in your distro advisory.
- Use your distro’s security tracker (Ubuntu/Debian/SUSE/etc.) and OSV/NVD entries to map the patched commits to package versions.
2. Look for the driver/module in a running kernel
- Check for device nodes: ls /dev | grep pci-endpoint-test
- Check kernel modules: lsmod | grep -E 'pci(_
?endpoint' - Check module info: modinfo pci_endpoint_test (or modinfo pci-epf-test)
- Inspect the IRQ list for evidence of the test driver: grep -R "pci-endpoint-test" /proc/irq
These commands reveal whether the module or device is present and active on a running host. The kernel driver can be built-in or modular; if built-in it will appear in the kernel configuration rather than as a module.
3. Inspect kernel configuration for config symbols
- Check /boot/config-$(uname -r) or /proc/config.gz for:
- CONFIG_PCI_ENDPOINT_TEST
- CONFIG_PCI_EPF_TEST
If stated as =m the driver is built as a module; if =y it’s built into the kernel image and will be present regardless of module loading. The canonical kernel config symbol is CONFIG_PCI_ENDPOINT_TEST (module name pci_endpoint_test); related endpoint function test driver is CONFIG_PCI_EPF_TEST (module pci-epf-test).
4. Check your images and artifact manifests
- For Azure Linux images, consume Microsoft’s VEX/CSAF attestation (MSRC publishes machine‑readable attestations) for the CVE to confirm whether Azure Linux kernels you use are listed as “Known Affected” or “Fixed.”
- For other Microsoft artifacts (WSL2 kernels, Marketplace images, embedded appliance kernels), don’t assume absence. Instead:
- Inspect image package lists and kernel versions.
- Where possible, boot a test instance and run the probing commands above.
- For WSL2, check the kernel repo and release notes for the kernel shipped with your WSL version.
5. Prioritize assets for remediation
- Multi‑tenant hosts, build agents, Marketplace image builders, and automation platforms should beoften instantiate multiple images and a single unpatched kernel can be widely reused.
- Developer and CI images that include test drivers may be more likely to contain pci_endpoint_test; production images can often be hardened by removing test drivers from builds.
Remediation and mitigation options
Preferred action: apply vendor patches / update kernel
- Apply the vendor or distribution kernel update that contains the upstream fix. Most mainstream distributions published advisories and patched package versions; use your distro’s patch guidance to pick the appropriate kernel package for your release.
Short‑term mitigations (if you cannot patch immediately)
- Unload or blacklist the module if it is built as a module and not required in production:
- Identify the module name (pci-epf-test).
- If safe, run: sudo modprobe -r pci_endpoint_test
- Prevent future loads by adding the module to a blacklist file (e.g., /etc/modprobe.d/blacklist-pci-endpoint-test.conf) with: blacklist pci_endpoint_test
Note: unloading succeeds only if the module is not in use. Test in non‑production first. - Rebuild kernel images without CONFIG_PCI_ENDPOINT_TEST (set it to N) if you produce custom kernels for appliances or images — this prevents the test driver from being present at all.
- For managed Azure Linux images, prefer the vendor-supplied kernel updates Microsoft publishes for Azure Linux; Microsoft’s VEX/CSAF is intended to guide which Azure Lfected and when fixes are applied.
Operational guidance: how to treat Microsoft’s attestation in your environment
- Treat MSRC’s Azure Linux attestation as authoritative foand kernels that Microsoft lists. If you run those images, patch them per Microsoft guidance immediately.
- For other Microsoft products and images (WSL2 kernel releases, Marketplace appliances, device firmware images that Microsoft distributes, or bespoke kernels used in Azure services), do not assume “not affected” just because MSRC has not yet attested them. Instead:
- Query Microsoft’s published VEX/CSAF entries (where available) for the CVE.
- Inspect the artifact (kernel config, module presence) directly.
- If artifact inspection is not possible, treat the artifact as “under investigation” and prioritize it for verification.
- If you find the pci_endpoint_test driver in a Microsoft-supplied artifact not covered by MSRC’s attestation, report that finding through your vendor / support channel and subscribe to the CVE’s MSRC entry for updates; Microsoft has publicly committed to update CVE pages when additional products are identified.
Why this distinction matters for supply‑chain security
The broader lesson is about inventory vs. exclusivity in public advisories. Microsoft’s VEX/CSAF rollout for Azure Linux makes their inventory work transparent and improves defenders’ ability to triage alerts. But:- An attestation that “product X includes the component” is useful and actionable for operators who run product X.
- It is not a statement that other products do not include the same component; many vendors ship multiple artifacts that may independently pull the same open‑source code into different images or builds (example: a WSL2 kernel build versus an Azure Marketplace VM kernel versus a managed Azure Linux image). Each artifact must be verified.
Final recommendation checklist
- If you run Azure Linux images: prioritize and apply Microsoft’s Azure Linux kernel updates referenced in the CVE/VEX entry.
- Inventory other Microsoft artifacts you run (WSL2 kernels, Marketplace images, Azure service kernels) and verify the presence of CONFIG_PCI_ENDPOINT_TEST or its modules. If present, schedule patching or module removal.
- For ephemeral or developer images, consider blacklisting the test driver or rebuild images without the test driver compiled in.
- Update vulnerability scanners and internal SBOMs to consume MSRC’s VEX/CSAF attestations for Azure Linux and to track any future MSRC updates that add additional Microsoft products to the CVE mapping.
- Monitor vendor advisories (NVD, Ubuntu, SUSE, Debian, Oracle) for distribution‑specific remediation steps and package versions; apply those updates according to your risk and deployment schedules.
Conclusion
Microsoft’s public wording about CVE‑2025‑23140 is precise: Azure Linux is a confirmed product that includes the affected open‑source component and is therefore potentially affected — and Microsoft will publish machine‑readable VEX/CSAF attestations for Azure Linux and expand those attestations if other Microsoft products are later found to ship the same upstream component. That statement does not, however, mean Azure Linux is the exclusive Microsoft product that could contain the pci_endpoint_test code. Defenders should treat the Azure Linux attestation as authoritative for Azure Linux, but they must still verify other Microsoft artifacts that they run and remediate accordingly. The technical fix is upstream and straightforward; the real work in enterprise environments is accurate inventory, prioritized patching, and ensuring artifacts do not silently carry unnecessary test drivers into production.Source: MSRC Security Update Guide - Microsoft Security Response Center
