Microsoft has published an advisory for CVE-2025-38624, a Linux kernel vulnerability that can trigger kernel panics in the PowerNV PCI hotplug driver. The company confirmed that its Azure Linux distribution contains the affected open-source code and is therefore potentially vulnerable, but it has not yet attested other Microsoft products that might include the same upstream kernel component.

What actually changed

CVE-2025-38624 addresses a resource management flaw in the Linux kernel’s pnv_php driver, which handles PCI hotplug events on PowerNV (IBM Power/NVIDIA) platforms. When a nested PCIe bridge configuration is unplugged, the driver fails to free interrupt request (IRQ) resources for child buses. In practice, that leak can lead to a kernel panic — essentially a host crash — during device removal.

The upstream fix, confirmed by the National Vulnerability Database and major distribution trackers, walks child buses to deallocate IRQs before removing hotplug devices and adjusts the lifetime of a workqueue so it is freed only in the safe teardown path. Those patches are now being backported by Linux vendors.

Microsoft’s advisory, delivered through the newer Common Security Advisory Framework (CSAF) and Vulnerability Exploitability eXchange (VEX) model, includes a brief FAQ: “Azure Linux includes this open-source library and is therefore potentially affected by this vulnerability.” It adds that the company began publishing CSAF/VEX attestations in October 2025 and will update the CVE entry if additional product impact is identified.

What it means for you

The immediate takeaway: if you run Azure Linux images — including those built on the CBL-Mariner lineage — treat this as an in-scope vulnerability for your environment. Microsoft’s attestation is authoritative for that product family, so patch as soon as fixes are released.

But Microsoft’s statement should not be read as a declaration that no other Microsoft artifact contains the same vulnerable code. Several technical realities make that impossible to conclude from a single product attestation:

  • Build provenance varies. The same upstream kernel file or commit can appear in many different build pipelines. Whether a specific Microsoft-distributed kernel (WSL2, linux-azure kernels, Azure Marketplace images, container host images) includes the pnv_php driver depends on the exact upstream commit series used and any backported fixes.
  • Kernel configuration matters. The driver may be compiled in or built as a module depending on CONFIG_PNV_PHP and related flags, which differ across artifacts.
  • Packaging and static linking. Appliance-style images or statically built kernel modules can carry the same upstream source without clear external indicators.

Thus, for administrators of other Microsoft products, the current absence of a VEX attestation is not evidence of safety. It means those artifacts remain unverified.

Who should care most:
- Azure Linux administrators: You have a confirmed, actionable vulnerability. Plan kernel updates immediately.
- IBM Power / PowerNV hardware operators: The affected driver is specific to that architecture. If your environment uses nested PCIe bridges and hotplug flows, prioritize patching.
- Anyone running Microsoft-distributed kernels in multi-tenant or cloud settings: A kernel panic in a shared host affects all tenants, making this a denial-of-service risk with potentially broad impact.
- Security teams relying on automated CVE scanners: Be aware that kernel version strings alone are not sufficient for verification — you’ll need to check upstream commit IDs or package changelogs.

The vulnerability is primarily a robustness/availability issue, not a remote code execution vector. Exploitability is low for external attackers, but practical risk increases in environments where automated device attach/detach (common in test, CI, or dynamic cloud setups) can trigger the unplug path.

How we got here

CVE-2025-38624 was assigned in 2025 after the upstream kernel community identified the IRQ leak. The fix landed in the mainline kernel and was subsequently backported by major distributions, including Ubuntu and Debian, whose security trackers now map the patch to their package versions.

Microsoft’s CSAF/VEX attestations are part of a broader transparency push that began in October 2025. The goal is to give security teams machine-readable signals about which products are known to be affected, reducing false positives. Azure Linux was among the first product families to be inventoried under this program, so its attestation serves as a model for how Microsoft intends to operate going forward.

The advisory’s FAQ wording—singling out Azure Linux—reflects a scoped inventory result, not a universal exclusion. In traditional vendor advisories, similar phrasing often led customers to misread the statement as a full product scope. Here, the machine-readable context is clearer, but the FAQ alone could still confuse teams that don’t dig deeper.

What to do now

A practical, prioritized checklist for defenders:

  1. Inventory your Linux kernel artifacts
    - List all hosts, VMs, and container images that run Microsoft-distributed kernels. Use uname -a to get kernel release strings, but remember these are not definitive.
    - For package-managed systems, query installed packages (dpkg -l for Debian/Ubuntu derivatives, rpm -qa for Mariner/Azure Linux).

  2. Check for the vulnerable driver
    - Examine kernel configuration: grep -i pnv_php /boot/config-$(uname -r) (or zcat /proc/config.gz). Look for CONFIG_PNV_PHP=m or =y.
    - Check loaded modules: lsmod | grep pnv_php.
    - Review kernel messages: dmesg | grep pnv_php for probe output.

  3. Match to vendor fixes
    - For Azure Linux, watch for Microsoft’s updated advisory with fixed package versions. Apply and reboot.
    - For other distros, consult their security trackers (Ubuntu’s USN, Debian’s DSA, Red Hat’s RHSA) and compare upstream commit IDs listed in the NVD entry with your kernel package changelogs.
    - If you maintain in-house kernel builds, verify that the upstream commits are cherry-picked (look for commit hashes from the stable tree backports).

  4. Temporary mitigations if patching is delayed
    - Restrict or disable automated hotplug operations, especially in CI/test environments where nested PCI topologies might be created and torn down frequently.
    - Restrict access to management interfaces (sysfs entries, IPMI, BMC) that can trigger device removal flows.
    - In virtualized environments, limit the ability of guests to trigger hot-unplug events on emulated PCI bridges.

  5. Monitor and detect
    - Add log alerting for kernel OOPS, panic, or IRQ/msi release failures (dmesg, journalctl -k). Correlate with device hotplug events.
    - Use security tools that consume CSAF/VEX feeds (when available) to flag artifacts that remain unverified.

Outlook

Microsoft’s commitment to expand VEX attestations beyond Azure Linux is a positive step, but the timeline remains unclear. Customers running other Microsoft-supplied kernels should proactively verify their exposure rather than awaiting attestations. In the long run, broader adoption of machine-readable vulnerability disclosures—combined with software bills of materials (SBOMs)—will make it easier to close such verification gaps. For now, treat CVE-2025-38624 as a concrete reminder that a single vendor advisory rarely tells the whole story.