A short, surgical change in the ACPI interpreter has rippled into a broader question for administrators and cloud operators: when Microsoft’s MSRC advisory says “Azure Linux includes this open‑source library and is therefore potentially affected,” does that mean Azure Linux is the only Microsoft product that could carry the vulnerability? The short answer is: Azure Linux is the only Microsoft product Microsoft has attested to so far, but it is not technically the only possible carrier — other Microsoft‑shipped kernels and images may include the same ACPICA code and should be inventory‑checked and verified.
The vulnerability tracked as CVE‑2025‑38386 affects the ACPI Component Architecture (ACPICA) implementation used as an AML interpreter in several operating systems. The underlying fault arises when a platform’s ACPI tables (AML) change the number of expected parameters for a method without updating callers, producing a mismatch that can lead to a crash and use‑after‑free in the interpreter. Upstream kernel maintainers addressed the issue by changing ACPICA to refuse evaluating methods when callers supply fewer arguments than the method expects — a defensive move that avoids creating missing data out of thin air and prevents the interpreter from executing in an inconsistent state.
Security databases began tracking CVE‑2025‑38386 in mid‑2025, and multiple advisory channels (upstream kernel, Linux distributors, and independent vulnerability trackers) document the technical cause, the fix, and the general mitigation strategy: patch the kernel and, where possible, update platform firmware to correct mismatched AML. Microsoft’s Security Response Center explicitly noted that Azure Linux includes the implicated open‑source library and is therefore potentially affected, and that Microsoft began publishing machine‑readable CSAF/VEX attestations for Azure Linux to make impact status clearer for customers. Microsoft also committed to updating CVE records if other products are later identified that ship the affected component.
Source: MSRC Security Update Guide - Microsoft Security Response Center
Background
The vulnerability tracked as CVE‑2025‑38386 affects the ACPI Component Architecture (ACPICA) implementation used as an AML interpreter in several operating systems. The underlying fault arises when a platform’s ACPI tables (AML) change the number of expected parameters for a method without updating callers, producing a mismatch that can lead to a crash and use‑after‑free in the interpreter. Upstream kernel maintainers addressed the issue by changing ACPICA to refuse evaluating methods when callers supply fewer arguments than the method expects — a defensive move that avoids creating missing data out of thin air and prevents the interpreter from executing in an inconsistent state.Security databases began tracking CVE‑2025‑38386 in mid‑2025, and multiple advisory channels (upstream kernel, Linux distributors, and independent vulnerability trackers) document the technical cause, the fix, and the general mitigation strategy: patch the kernel and, where possible, update platform firmware to correct mismatched AML. Microsoft’s Security Response Center explicitly noted that Azure Linux includes the implicated open‑source library and is therefore potentially affected, and that Microsoft began publishing machine‑readable CSAF/VEX attestations for Azure Linux to make impact status clearer for customers. Microsoft also committed to updating CVE records if other products are later identified that ship the affected component.
Why the wording matters: "includes" vs. "only"
Microsoft’s advisory language is careful and product‑scoped. Saying a product “includes this open‑source library and is therefore potentially affected” performs two jobs:- It confirms inventory: Microsoft has verified this component is present in the named product family (Azure Linux).
- It signals scope management: Microsoft will update the record if analysis finds the same component in other Microsoft products.
Technical overview: what CVE‑2025‑38386 really is
The bug in plain terms
ACPICA interprets AML (ACPI Machine Language), a small bytecode language embedded in firmware ACPI tables used by the operating system to discover and configure devices, manage power states, and run platform methods. The reported flaw occurs when:- A platform firmware update increases the number of parameters of an AML method (i.e., the method signature changes at the firmware layer),
- A caller to that method remains unchanged and continues invoking it with the older, smaller set of parameters,
- The mismatch causes ACPICA to proceed into a code path where memory-management assumptions break, leading to a use‑after‑free or crash.
Why this matters in the kernel
ACPI code runs with kernel privileges. Interpreting AML incorrectly can crash the kernel (resulting in a denial‑of‑service) and, in the worst case with memory corruption, can enable privilege escalation or other remote/local attack vectors depending on context. Because AML originates in platform firmware, attack vectors often require either:- A malicious or buggy firmware image supplied by a vendor or installer, or
- A platform where attacker control of certain firmware tables is possible (e.g., untrusted VM images, or supply‑chain compromises).
Which Microsoft products could plausibly include ACPICA?
Microsoft’s statement specifically attests to Azure Linux. However, other Microsoft‑distributed kernels or kernel artifacts can — and in some cases demonstrably do — contain ACPICA code. Valid candidates include:- Windows Subsystem for Linux (WSL) kernel images: Microsoft maintains a public WSL2 kernel repository and ships kernel binary images for WSL; those kernel trees have historically included the Linux drivers/acpi/acpica subdirectory. That means the WSL kernel artifacts used in some deployments could contain ACPICA code and therefore deserve verification.
- Azure host images and internal Linux kernels: Microsoft builds and ships various Linux artifacts for Azure infrastructure and Marketplace images (container hosts, custom VM images). Any of these artifacts that include a Linux kernel built from code that pulls in ACPICA could be affected.
- Vendor‑supplied or partner images distributed through Microsoft channels: Marketplace appliances and partner images often base on Linux kernels that may have ACPICA compiled in.
- Non‑Windows Microsoft products that embed or ship Linux: container hosts, appliance images, and specialized devices or services that bundle Linux kernels.
What is not established (and must be treated cautiously)
- There is no authoritative Microsoft statement saying that Windows desktop or Windows Server image ships ACPICA as part of the native Windows kernel. Internal Windows ACPI handling historically uses Windows’ own ACPI driver stack (acpi.sys and related components), not necessarily the ACPICA codebase. That said, Intel distributes Windows‑format ACPICA sources and tools, but availability in those sources does not equal presence in shipping Windows builds. This is an example of an unverifiable claim without direct artifact inspection or a vendor attestation — treat such inferences as possible but unconfirmed.
How to determine whether a given Microsoft artifact is affected
Operators should follow a two‑track approach: consume vendor attestations (VEX/CSAF) and perform artifact‑level checks.1) Consume Microsoft’s machine‑readable attestations (CSAF/VEX)
- Microsoft publishes CSAF advisories and VEX attestations for select products. Use those files as the canonical vendor signal for the named artifacts (Azure Linux is confirmed in Microsoft’s rollout).
- VEX will typically carry a per‑product decision: Not Affected, Under Investigation, Known Affected, or Fixed. If Microsoft lists a product as “Not Affected” in VEX, you can treat that as the vendor’s attestation for that product, subject to your compliance requirements.
2) Perform artifact checks for any image or kernel you run
- For Linux kernels: inspect the kernel tree or the compressed kernel image and look for drivers/acpi/acpica (or for compiled object symbols referencing ACPICA). On source trees, presence of the drivers/acpi/acpica directory is a strong indicator.
- For shipped kernel images: extract the kernel (vmlinuz) and search strings or symbol tables for ACPICA identifiers or iASL/ACPICA utilities. Example quick checks:
- Uncompress the kernel image and run strings | grep -i acpica or strings | grep -i acpi to spot in-tree markers.
- For distributions that include build metadata, check package manifests for acpica packages or kernel config options enabling ACPI interpretation code.
- For WSL kernels: check the public WSL2 kernel repository or the specific WSL kernel binary used by your machines. Microsoft’s WSL GitHub tree has historically contained acpica sources under drivers/acpi.
- For container or appliance images: run a container or VM, then query uname -a, /boot config data, or examine /proc/config.gz for CONFIG_ACPI options and kernel version ranges known to include the vulnerability.
3) Map kernel version and commit ranges
- Upstream advisories for the CVE will typically identify the kernel commits that introduced or fixed the problem. Where your artifact’s kernel build includes those commits, treat it as affected until patched.
- If precise commit mapping is difficult, err on the side of caution: prioritize image updates and planned patching if you run Microsoft artifacts that include Linux kernels (WSL, Azure images, Marketplace appliances).
Operational risk and exploitability: what admins need to know
- Severity: Public trackers classify this as a kernel‑level vulnerability that can cause crashes and memory corruption (use‑after‑free). That places it in a moderate‑to‑high severity profile for affected systems.
- Exploitability: The practical exploit requires control or corruption of ACPI tables (firmware), or running on a platform where malicious or buggy AML can be supplied. That makes some environments higher risk:
- Multi‑tenant host OSes and cloud images that ingest various VM images or containers are more exposed if they host untrusted guest images.
- Systems accepting firmware updates from vendors, or receiving third‑party hardware with buggy ACPI tables, could be affected.
- Attack vectors:
- Denial‑of‑Service (kernel crash) is the simplest and most likely outcome.
- Privilege escalation or code execution would require specific memory‑corruption exploitation; such exploitation paths are harder but cannot be ruled out on complex kernels.
- Windows desktop/laptops: typical Windows systems rely on Windows’ own ACPI handling; the extent to which ACPICA itself exists within Windows shipping kernels is not established and thus Windows desktops should be treated as lower‑probability carriers until Microsoft’s attestations or artifact checks indicate otherwise.
Recommended mitigation and response plan
The practical response plan for organizations that use Microsoft artifacts should be layered and prioritized by exposure risk.Immediate actions (first 72 hours)
- Treat Azure Linux instances as confirmed potentially affected and prioritize patching or staging updates according to Microsoft’s VEX/CSAF guidance.
- If you run WSL at scale (WSL2 kernel images), validate which WSL kernel version your fleet uses and check for presence of ACPICA code or published vendor advice. If a patched WSL kernel is released, plan for deployment.
- For Azure Marketplace and custom images, inventory all images and kernels. Flag images that run updated kernels and schedule patching for images with vulnerable kernels.
- For high‑value hosts that run untrusted guest images or accept Marketplace images, reduce the attack surface: limit image ingestion, use image scanning, and isolate hosts until patched.
Short‑term (1–2 weeks)
- Apply upstream kernel updates for distributions that publish patches against CVE‑2025‑38386. For Azure Linux, consume Microsoft’s security updates as supplied and apply them in a controlled rollout.
- Check firmware updates from hardware vendors; if a vendor supplies corrected ACPI/AML tables, prioritize firmware upgrades those hosts.
- For organizations that rely on Microsoft’s CSAF/VEX files for automated triage, integrate Azure Linux VEX into your automation and watch for Microsoft updates that expand the product scope.
Medium‑term (1–3 months)
- Harden operations by applying strict image provenance controls for all Linux images and kernels in your environment, including WSL instances where applicable.
- Add artifact checks into your CI/CD: ensure new images pass an inventory check for known vulnerable components such as ACPICA and flagged kernel versions.
- Where feasible, add runtime mitigations like kernel hardening, memory protection features, and minimizing the use of features that interpret external bytecode-like inputs.
Detection and forensic guidance
- Kernel crash signatures: look for ACPI‑related stack traces in dmesg, kern.log, or system crash dumps showing acpi/ACPICA function names or AML interpreter traces.
- Memory corruption artifacts: unusual kernel oopses or backtraces that reference ACPICA internal routines are reliable indicators.
- Audit firmware/ACPI tables: use acpidump/iasl to extract and disassemble ACPI tables and look for method signatures that changed or obviously malformed AML.
- If you suspect exploitation: collect crash dumps, preserve kernel images, and extract the ACPI tables from affected hosts for offline analysis.
Practical examples: what to check on common Microsoft artifacts
- Azure Linux (confirmed attestation): consume Microsoft’s updates and VEX files; patch hosts using standard Azure update channels and distro packages.
- WSL2 on developer endpoints and servers:
- Identify whether your environment uses the default Microsoft WSL kernel or a custom kernel.
- For default WSL kernels, watch for Microsoft WSL kernel releases and security advisories; deploy updates through normal WSL update mechanisms or via Windows Update when supplied.
- Azure Marketplace appliances and containers:
- For marketplace images, check the image manifest and vendor advisories for kernel versions and ACPICA presence.
- For container hosts, verify the host kernel rather than container images; the host’s ACPICA library is what matters.
Strengths and weaknesses of Microsoft’s current approach
Strengths
- Transparency via CSAF/VEX: Microsoft’s publication of machine‑readable VEX attestations is a major step forward. It enables automation and reduces uncertainty by declaring product‑specific impact decisions for named artifacts.
- Conservative wording: By attesting to Azure Linux first and committing to update mappings, Microsoft reduces risk of overbroad claims while providing a clear known‑affected signal.
- Incremental rollout: Focusing on a single product first (Azure Linux) allows Microsoft to validate procedures and data quality before scaling VEX publishing to many products.
Weaknesses / risks
- Inventory lag: VEX is only as useful as the vendor’s ability to inventory every product and build artifact. Until Microsoft completes that work, other artifacts may remain unverified.
- Operational complexity for customers: Many organizations run mixed Microsoft artifacts (WSL kernels, Azure host images, Marketplace appliances). Customers must still perform artifact‑level checks rather than relying solely on vendor statements.
- Potential for misunderstanding: Careless reading of the MSRC advisory might lead some operators to assume only Azure Linux is at risk. That misinterpretation could delay necessary checks of other images or WSL kernels.
Final assessment and recommended posture
- Azure Linux is a confirmed potential carrier of the ACPICA code related to CVE‑2025‑38386 — Microsoft verified this and published VEX attestations starting with Azure Linux. Treat Azure Linux accordingly: prioritize patching and monitor Microsoft’s VEX/CSAF for update status changes.
- Azure Linux is not necessarily the only Microsoft product that could include ACPICA. WSL kernels and other Microsoft‑distributed Linux artifacts are plausible carriers and should be independently inspected.
- The safest operational stance is to combine vendor attestations (VEX/CSAF) with artifact‑level verification. Do not treat a single product attestation as an implicit statement about all Microsoft products.
- Implement a prioritized patching and inventory program: confirm which kernels and images you run contain ACPICA, apply patches promptly, and harden hosts where untrusted code or firmware can be introduced.
Source: MSRC Security Update Guide - Microsoft Security Response Center
