Microsoft has confirmed that Azure Linux is affected by a newly disclosed Linux kernel vulnerability (CVE-2025-38487) that can crash systems running the Aspeed LPC-snoop driver. The advisory, however, does not address whether other Microsoft-provided Linux products—including WSL kernels, Azure Marketplace images, and custom IoT appliances—are also vulnerable, leaving administrators to manually verify their exposure.

What actually changed

CVE-2025-38487 is a bug in the Linux kernel’s Aspeed LPC-snoop driver, publicly disclosed on July 28, 2025. The flaw causes a NULL pointer dereference when channels that were never enabled are disabled during device removal, resulting in a kernel oops and potential system crash. It carries a CVSS v3.1 score of 5.5 (Medium), primarily affecting availability. Exploitation requires local access or the ability to trigger the vulnerable remove/unbind code paths.

On its Security Response Center (MSRC) page, Microsoft published a machine-readable VEX/CSAF attestation stating: “Azure Linux includes this open‑source library and is therefore potentially affected.” This is part of a new transparency push that began in October 2025, when Microsoft started issuing CSAF/VEX documents for open-source components—starting with Azure Linux. The FAQ section of the advisory explains the limited scope: “If impact to additional products is identified, we will update the CVE to reflect this.” No other Microsoft product family is mentioned.

What it means for you

The impact differs sharply depending on which Microsoft Linux artifacts you run.

Azure Linux users

If you deploy Azure Linux, the advisory is authoritative. You are affected, and you must treat this as an active vulnerability in your environment. Fortunately, because Microsoft has explicitly confirmed the presence of the vulnerable component, you know exactly where to focus patching efforts. No further verification is needed—just get the fixed kernel packages as soon as they are released.

WSL2 users

Microsoft has not attested any WSL kernel builds. Whether a WSL instance is affected depends on the kernel version build configuration. Some WSL kernels may include the aspeed LPC-snoop driver, either compiled in or as a loadable module. Until Microsoft adds WSL to the advisory, you cannot assume immunity. You must manually inspect your WSL kernel and modules.

Azure Marketplace images and custom linux-azure builds

Images published by Microsoft or third parties on the Azure Marketplace are separate artifacts. Microsoft’s Azure Linux attestation does not extend to these images, even if they are based on the same upstream kernel sources. Likewise, any linux-azure kernel builds for VM hosts, container hosts, or service images are distinct and unverified. Treat them all as potentially affected until the publisher provides an explicit SBOM or vulnerability statement.

Embedded and IoT appliances

If you use Microsoft‑supplied or partner‑built embedded Linux images for appliances, the aspeed driver could be present, especially on hardware that uses Aspeed BMCs. These devices often lag behind in patching and rarely include SBOMs, so they represent the highest risk of lingering exposure. Verify each device independently.

Security teams

This incident highlights a critical operational principle: vendor VEX/CSAF attestations are product‑scoped. A “known affected” statement for one product tells you nothing about others. Automation that triages vulnerabilities based solely on vendor attestations must be tuned to treat unattested products as unknown risk, not clean. Until the VEX rollout covers your full inventory, you must supplement with local artifact checks.

How we got here

Microsoft’s phased approach to vulnerability transparency is relatively new. In October 2025, the company announced it would begin publishing CSAF/VEX for open-source components, starting with Azure Linux. The rationale: Azure Linux is a curated distribution where Microsoft can tightly control component versions and inventory, making it the logical first product family. Over time, the plan is to expand attestations to other Microsoft products that ship open-source libraries.

CVE-2025-38487 itself surfaced on July 28, 2025, and quickly appeared in advisories from major distributions. Ubuntu, Debian, Amazon Linux, and others published backports and patches. When Microsoft’s MSRC entry went live, it followed the new VEX pattern—attesting only to Azure Linux. The advisory’s FAQ makes the inventory scope explicit: Microsoft has checked Azure Linux, found the component, and declared it affected. For everything else, the work is not yet complete. That’s not a guarantee of safety; it’s a disclosure that the inventory is still underway.

What to do now

1. Patch Azure Linux immediately

Monitor the MSRC page and your Azure Update Manager for kernel updates addressing CVE-2025-38487. Apply them as soon as they are released, and schedule necessary reboots.

2. Inventory all other Microsoft‑supplied Linux artifacts

Create a list of every Microsoft‑related Linux image in your estate:

  • WSL2 instances on developer workstations
  • VM host kernels (linux-azure)
  • AKS node images
  • Marketplace VM images
  • IoT or embedded appliances

3. Verify the presence of the vulnerable driver

On each live system, run these commands:

uname -a                # kernel version
lsmod | grep aspeed      # loaded aspeed modules
find /lib/modules/$(uname -r) -type f -name 'aspeed'

Check kernel config if available:

zgrep ASPEED /proc/config.gz # or zgrep ASPEED /boot/config-$(uname -r)

If you see aspeed modules, or CONFIGASPEEDLPCSNOOP set to y or m, the driver is present. Compare the kernel version to the fixed commit ranges (upstream fixes have been merged into stable trees—references are available in public CVE databases).

For offline images, mount the image and examine /lib/modules/ and kernel config files.

4. Apply temporary mitigation if patching is delayed

If you confirm the driver is present and a fix is not yet available, you can unbind the device to prevent exploitation. Warning: This may disable Console Redirection or other management features that rely on LPC snooping.

echo <device-name>.lpc-snoop > /sys/bus/platform/drivers/aspeed-lpc-snoop/unbind

Replace <device-name> with the actual platform device name (e.g., 1e789000.lpc-snoop). Check dmesg or /sys/bus/platform/devices/ to find the correct name.

Additionally, restrict access to device nodes and review orchestration workflows that might allow tenants to trigger device removal operations.

5. Demand SBOMs from third-party publishers

For Azure Marketplace images and partner appliances, require vendors to provide a Software Bill of Materials (SBOM) or a vulnerability attestation that covers CVE-2025-38487. Refuse to deploy unverified images into production until their patch status is confirmed.

6. Monitor for exploitation attempts

Look for kernel oopses with call traces pointing to aspeedlpcsnoopremove or platform_remove. These are telltale signs that the vulnerable code path is being triggered. Set up alerts in your SIEM or logging platform.

Outlook

Microsoft has stated it will update the CVE when additional products are identified as affected. With the phased VEX rollout, expect attestations for WSL, linux-azure, and other product lines to appear over the coming months. Until then, proactive verification is the only safe path.

This episode also signals a broader industry shift toward machine-readable vulnerability statements. CSAF and VEX are powerful tools for automating triage, but their value depends entirely on completeness. As more vendors adopt similar transparency practices, the current state of partial attestation will gradually improve. For now, treat every unattested artifact as a potential risk, and verify.