CVE-2025-38113: Azure Linux Attestation and Microsoft VEX CSAF Visibility

Microsoft’s short MSRC line — that “Azure Linux includes this open‑source library and is therefore potentially affected by this vulnerability” — is accurate as an inventory attestation, but it is not a technical guarantee that no other Microsoft product could contain the same vulnerable code; Azure Linux is simply the Microsoft product Microsoft has publicly validated so far. ps://www.microsoft.com/en-us/msrc/blog/2025/10/toward-greater-transparency-machine-readable-vulnerability-exploitability-xchange-for-azure-linux)

Background / Overview​

CVE‑2025‑38113 is a recent Linux‑kernel fix that addresses a NULL‑pointer dereference in the ACPI CPPC (Collaborative Processor Performance Control) support. The bug surfaces when the kernel is booted with the kernel parameter nosmp: other CPUs are not brought up, leaving their per‑CPU CPPC descriptor pointers (cpc_desc_ptr) as NULL; CPU0’s loop that iterates over possible CPUs then dereferences those NULL pointers and the kernel panics. The vulnerability was recorded in upstream trackers and packaged by distributions; NVD and multiple distro trackers describe the issue and link to the upstream patch.
Upstream maintainers fixed the problem by making a defensive change in the CPPC helper — replacing the broad for_each_possible_cpu() iteration with a version that only visits present CPUs, preventing dereferencing NULL per‑CPU pointers when other CPUs were never brought online. The public patch and patch message are simple and clear: change for_each_possible_cpu() to for_each_present_cpu() in drivers/acpi/cppc_acpi.c. That small change stops the kernel panic in the nosmp boot case.
Why this matters to administrators: the bug yields an availability (denial‑of‑service) impact — kernel panic during boot — not a remote code‑execution vector. However, the crash happens early in boot if nosmp is used, so systems relying on that parameter (troubleshooting kernels, specialized single‑CPU configurations, recovery images, or certain embedded/experimental topologies) can become unbootable until patched. Public trackers report medium severity (CVSS ~ 5.5) with an availability impact and a local attack vector.

---

What Microsoft published — and how to read it​

Microsoft’s Security Response Center (MSRC) has adopted a machine‑readable attestation program (CSAF/VEX) and has begun publishing product‑level impact attestations starting with Azure Linux. In a number of MSRC CVE pages the company uses a concise FAQ answer along the lines of: “Azure Linux includes this open‑source library and is therefore potentially affected by this vulnerability.” Microsoft also explicitly stated it began publishing CSAF/VEX attestations in October 2025 and will update CVE mappings if additional Microsoft products are identified as affected. (microsoft.com)
That MSRC language performs two separate functions that are easily conflated:

• It is a product‑scoped inventory attestation: Microsoft has inspected the build outputs for the Azure Linux distribution and confirmed that the implicated upstream component (in this case, the kernel CPPC code) appears in those artifacts. That makes Azure Linux a confirmed known affected product for operators who run those images.
• It is not an exclusivity statement. The phrase does not and practically cannot prove that no other Microsoft product contains the same vulnerable upstream code. MSRC’s attestation says what Microsoft has checked to date and how Microsoft will expand transparency going forward; it does not exhaustively scan or enumerate every binary, image, SDK, marketplace appliance, or agent Microsoft publishes. Treat the attestation as authoritative for Azure Linux — but treat it as an incomplete inventory for the company’s entire ecosystem until VEX/CSAF coverage is expanded.

Multiple WindowsForum analyses (community and advisory explainers) emphasize the same point: Azure Linux is the product Microsoft has publicly declared as containing the component, and Microsoft will update its VEX/CSAF attestations if/when additional Microsoft products are discovered to ship the same code. The practical security posture for operators therefore splits into two actions: prioritize Azure Linux patching immediately, and simultaneously perform artifact‑level discovery across other Microsoft images and binaries you run.

---

Short, direct answer to the user’s question​

No — Azure Linux is not necessarily the only Microsoft product that could include the vulnerable CPPC code. It is the only Microsoft product Microsoft has publicly attested (so far) to include that upstream code for CVE‑2025‑38113. That attestation is authoritative and actionable for Azure Linux customers, but it should not be interpreted as a global exclusivity guarantee for all Microsoft artifacts.

---

Technical verification (what I checked and where)​

I validated three core factual elements and cross‑referenced them against independent sources:

• The bug description and crash backtrace (nosmp causing NULL cpc_desc_ptr dereferences) — corroborated by NVD and distro trackers.
• The upstream fix (changing for_each_possible_cpu → for_each_present_cpu in drivers/acpi/cppc_acpi.c) — visible in the kernel patch submission and in the publicly posted patch message. This is the authoritative upstream change that eliminates the crash path in the nosmp case.
• Microsoft’s product‑level attestation and VEX/CSAF rollout: MSRC’s blog announcing machine‑readable VEX attestations and the phrasing used in MSRC CVE pages that identify Azure Linux as “including the open‑source library” were used to confirm Microsoft’s public stance and the scope of the attestation program.

Where the public record was less complete I flagged it: for example, Microsoft’s public attestation does not list every Microsoft artifact and therefore cannot be used alone to prove other Microsoft products are not affected; additional product mappings may appear later as MSRC’s VEX coverage expands. That conditional nature is explicitly stated by Microsoft and repeats across advisory texts and FAQ language.

---

Why Azure Linux was singled out — and why that matters​

Microsoft began its CSAF/VEX program with Azure Linux because that product family is a natural and bounded starting point: Microsoft maintains the distribution, publishes its SBOMs and build outputs, and can assert the presence (or absence) of third‑party components with high confidence. By starting with a Microsoft‑maintained distro, MSRC provided a predictable, machine‑readable signal that opermatically into vulnerability management pipelines. This is a pragmatic approach: starting with a single product reduces complexity while establishing a repeatable attestation process.
But several technical realities make the attestation non‑exclusive:

• Microsoft ships a wide variety of artifacts (VM images, Marketplace appliances, WSL kernelelemetry agents, and container base images). Each artifact is built separately and may include different kernel versions, backports, and compiled drivers. A given upstream change appears in an artifact only if the build includes the vulnerable commit range or the backported fix. That makes presenild‑time property.
• Kernel drivers such as CPPC are compiled into kernels or modules based on build configuration flags. A single source file in upstream trees does not automatically mean every Microsoft kernel will include it: whether the driver is present depends on the chosen kernel configuration and build process for that artifact. But it is easily possible for the same driver code to appear in multiple Microsoft kernels (for example WSL kernels and some Azure VM SKUs), so absence of an attestation is an unknown, not proof of absence.
• Microsoft’s vcpkg and other internal or developer toolchains can make upstream libraries available to developers and build pipelines; those artifacts can propagate into larger products if care is not taken. This is another channel by which open‑source code can migrate into unexpected places.

Taken together: the Azure Linux attestation is useful and high‑confidence for that product family; it is not a global landscape scan for every Microsoft artifact.

---

Practical detection: how to tell if a system you manage is vulnerable​

Below are pragmatic steps to determine exposure and to triage quickly. Apply them in the order shown.
1.) Identify Azure Linux hosts and patch status (immediate priority)

• Check whether any of your VMs, nodes, or images are running Azure Linux (Azure Linux 2.x / Azure Linux 3.x / osSku AzureLinux3). Use your inventory system, cloud asset tags, or the Azure portal. If you are running Azure Linux, treat those images as confirmed high priority for kernel updates. Microsoft has published VEX/CSAF attestations and is patching Azure Linux images accordingly.

2.) Check kernel version on suspect hosts

• On each Linux host run: uname -a
• Compare the kerendor’s advisory that maps fixed kernel package versions (distributions will publish the exact package names or kernel revisions that include the upstream fix). For Debian/Ubuntu/SUSE/Red Hat/ALAS consult vendor advisories. Public trackers and distros list the patched package numbers; if your kernel predates the fixed package you must plan an update.

3.) Detect the presence of CPPC code in a kernel binary (advanced)

• If you need artifact‑level proof, inspect the kernel binary or module list for CPPC-related symbols (for example, search System.map or use nm/objdump on your kernel image) and check whether drivers/acpi/cppc_acpi.c is present in the build. Kernel config flags (CONFIG_ACPI_CPPC and related options) determine whether the code compiled in. This is a more technical check useful for appliance images and Marketplace images. (If you don’t maintain the image builds, ask the image vendor for an SBOM or VEX/CSAF attestation.)

4.) Check early boot logs for symptoms

• If a host experienced this bug it typically panicked very early and left kernel oops logs or crash dump records showing cppc_allow_fast_switch in the backtrace. Look for kernel panic tracebacks mentioning cppc_allow_fast_switch or NULL pointer dereference at an offset near a per‑CPU structure. Upstream advisories include sample backtraces.

5.) Inventory related Microsoft artifacts (do not assume “not mentioned” == safe)

• List Microsoft images you run: Marketplace images, AKS node images, WSL kernel versions, custom VM images created from Microsoft base images, and any Microsoft-supplied build containers or SDKs in use.
• Where possible, collect SBOMs for those images or request VEX/CSAF attestations from Microsoft for artifacts you rely on; Microsoft has committed to expanding VEX coverage beyond Azure Linux over time.

---

Remediation & mitigation (action checklist)​

• Patch Azure Linux images immediately
• Prioritize applying the kernel update from Microsoft for Azure Linux images and rebuild any dependent nodepools or images. Tenable/scan rules and many distro advisories list Azure Linux patches tied to this CVE. Reboot hosts after applying kernel updates where required.
• Patch other Linux hosts according to vendor advisories
• If you run non‑Azure Linux distributions, follow Debian/Ubuntu/Red Hat/SUSE/others for the precise fixed kernel packages or livepatch updates. The upstream fix is merged; distributions shipped fixes at different times and package names differ.
• Scan and inventory Microsoft artifacts beyond Azure Linux
• Do not assume that because MSRC named Azure Linux other Microsoft artifacts are automatically safe. Scan your cloud images, containers, Marand WSL kernels for the presence of the CPPC code or kernel versions predating the fix. If you find an image that contains the vulnerable build, patch or replace it.
• Use SBOMs, VEX/CSAF, and automated tools
• Ingest Microsoft’s CSAF/VEX attestations as they become available. Where VEX attestations are not yet published, use SBOMs, image scanning tools, and binary inspection to produce your own per‑artifact attestations. Microsoft has started publishing VEX for Azure Linux; expect the company to add further products over time.
• Staging and livepatch strategies
• For large fleets where immediate reboots are operationally costly, consider vendor livepatch services or staged rollouts with thorough smoke and regression testing. Livepatches can mitigate availability exposure in some cases; however, for kernel logic fixes that touch early boot code, a full reboot into a patched kernel is often the reliable remedial action.
• Update image build pipelines and CI
• Ensure build pipelines no longer bake vulnerable kernel builds into base images. Pin to patched kernel tree snapshots and coordinate rebuilds for any appliance images or custom kernels. Where third‑party vendors supply images, require SBOMs or attestations as part of procurement or deployment gating.

---

Recommended posture for Microsoft customers​

• Treat the MSRC Azure Linux attestation as a high‑confidence, high‑priority remediation signal for Azure Linux images: patch and reboot those hosts first. Microsoft’s VEX/CSAF attestations and follow‑up patches are intended to make this rapid and machine‑readable.
• Simultaneously, do not treat the absence of an MSRC attestation for another Microsoft product as proof that product is unaffected. Until Microsoft publishes an explicit “Not Affected” or “Known Affected” VEX entry for other product families, perform artifact‑level verification across any Microsoft images or binaries you run. This includes WSL kernels, AKS node images, Marketplace appliances, and custom images created from Microsoft bases.
• Integrate VEX/CSAF ingestion and SBOM checks into your vulnerability management: automated attestation ingestion reduces the human review burden and stops teams from assuming safety when inventory is incomplete. Microsoft’s phased rollout of VEX is explicitly designed to support this approach.

---

Risks, pitfalls, and caveats​

• Vendor attestations are only as complete as the vendor’s inventory process. Large vendors ship thousands of artifacts; discovering every carrier of a particular upstream file takes time. Microsoft has stated it will update CVE pages and VEX attestations as it discovers additional products that include implicated open‑source components. While Azure Linux was the first attested product in Microsoft’s VEX rollout, additional mappings may follow. Treat vendor statements as actionable guidance — but pair them with your own artifact scanning to close blind spots.
• The fix is small, but operational complexity remains. Kernel patches often require reboots, and some environments (large cloud fleets, appliances, or embedded devices) need careful staging. Livepatches may help in the short term but are not always appropriate for changes that touch early boot logic. Plan reboots, validate kernel module ABI compatibility (third‑party modules might need recompilation), and schedule rollouts during maintenance windows where possible.
• This CVE is availability‑focused. There is no indication this is an information‑disclosure or remote RCE flaw; however, availability bugs can cause service outages and data loss when crashes occur at inopportune times. Prioritize systems where uptime and boot reliability are critical.

---

Bottom line and recommended next steps (concise)​

• If you run Azure Linux images, apply Microsoft’s kernel update for CVE‑2025‑38113 immediately and reboot affected hosts. Treat this as a high‑priority remediation.
• For other Linux hosts, consult your distribution’s security advisory and update kernels or apply livepatches according to vendor guidance. Confirm the fix is present by checking the fixed package versions or the presence of the upstream patch.
• Do not assume other Microsoft products are safe simply because MSRC named Azure Linux. Perform artifact‑level scanning and request SBOMs/VEX attestations where you rely on Microsoft images or kernels. Use Microsoft’s VEX feed once it is available for the product in question.
• Integrate attestation ingestion and SBOM checks into CI/CD and asset management. That reduces manual blind spots and ensures you can react faster when vendors expand VEX coverage.

---

Final assessment​

CVE‑2025‑38113 is a straightforward yet practical availability bug that was fixed upstream with a small, defensive change. Microsoft’s public statement that Azure Linux includes the implicated component and is therefore potentially affected is a correct, product‑scoped attestation and reflects Microsoft’s phased VEX/CSAF rollout. However, that one‑line attestation does not prove exclusivity: other Microsoft artifacts could contain the same upstream CPPC code depending on kernel versions, build configurations, and backports. Operators should treat Azure Linux as an immediate remediation priority while simultaneously performing artifact‑level discovery and scanning across other Microsoft images and kernels they deploy. Patch, reboot, and use SBOMs and VEX to convert unknowns into knowns.
Conclusion
The vulnerability is fixed upstream; Microsoft has called out Azure Linux as a known carrier and is publishing machine‑readable VEX attestations. That’s progress. But operational security for large, heterogeneous estates always requires two things together: vendor attestation plus your own artifact verification. Prioritize Azure Linux updates now, scan the rest of your Microsoft images, ingest Microsoft’s VEX data as it arrives, and plan patched reboots with appropriate staging and validation.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center