CVE-2025-38591: Azure Linux attestation explains inventory scope

Microsoft’s public advisory language means: Azure Linux is the only Microsoft product the company has publicly attested so far to ship the upstream Linux kernel code mapped to CVE‑2025‑38591, but that is an inventory attestation — not a guarantee that no other Microsoft artifact could contain the same upstream code. What Microsoft actually said (short answer and why it matters)

• Short, direct answer: No — Azure Linux is not necessarily the only Microsoft product that could include the affected open‑source kernel code. It is, however, the only Microsoft product Microsoft has publicly listed as “includes this open‑source library and is therefore potentially affected” for this CVE at the time of their advisory.
• Why that wording matters: Microsoft’s statement is a product‑scoped VEX/CSAF attestation reflecting the inventory work it has completed to date. It tells customers which Microsoft product images the vendor has checked and marked as in‑scope; it does not, by itself, prove that other Microsoft SKUs, images, kernels or embedded artifacts cannot contain the vulnerable code. Microsoft has said it will update the advisory and VEX/CSAF attestations if further product impact is identified.

What the CVE is and who else tracks it

• CVE‑2025‑38591 is an upstream Linux kernel BPF verifier / context‑access correctness fix described in the kernel commits and tracked by major vulnerability databases. The kernel community and distro trackers (NVD, Debian, Ubuntu, SUSE, etc. describe the issue and list the upstream fixes / commits.
• Distributors are packaging backports and fixed kernel releases independently; the canonical mitigation for affected hosts is to install the vendor/distributor kernel update that contains the upstream fix.

Why Microsoft’s attestation doesn’t equal exclusivity

• Attestations are scoped, phased, and product‑specific. Microsoft began publishing machine‑readable CSAF/VEX attestations starting with Azure Linux (CBL‑Mariner lineage), which explains why Azure Linux appears first in Microsoft’s published attestations for many upstream CVEs. That initial mapping reflects the inventory work already completed, not a final global statement about every Microsoft product or image.
• Microsoft ships many distinct artifacts that can independently include Linux kernel code: Azure Marketplace images, managed linux kernels used by cloud services, AKS node images, container base images, Windows Subsystem for Linux (WSL2) kernels, and any internally built images that incorporate upstream kernel code. Each artifact’s build configuration (kernel version, config toggles, modules built‑in vs modules, backports) determines whether the problematic code is present. Until each artifact is inventoried and attested, absence from VEX ≠ absence of the component.

How you (or your organization) can verify exposure right now (practical steps)
1) Treat Microsoft’s statement for Azure Linux as high‑priority action

• If you run Azure Linux images or depend on Microsoft’s Azure Linux kernel packages, treat the VEX/CSAF attestation as an authoritative indicator that you must patch: apply Microsoft’s Azure Linux kernel updates or redeploy patched images as directed in Microsoft guidance.

2) Inventory other Microsoft artifacts you run

• Make an inventory of Microsoft‑published images or artifacts you consume: Marketplace VM images, AKS node images, WSL2 kernels, Microsoft container base images, and any VM images derived from Microsoft images.
• For each artifact, ask: does it include a Linux kernel build (or a packaged kernel) — and if so, which kernel version and configuration? If you cannot rely on vendor attestations yet, perform artifact inspection and SBOM/SCA scans.

3) Quick host checks (commands you can run on suspect Linux VMs)

• Find the kernel version and whether BPF support and context fields are present:
• uname -a
• zgrep CONFIG_BPF /proc/config.gz || grep -w CONFIG_BPF /boot/config-$(uname -r)
• grep -i bpf /boot/config-$(uname -r)
• lsmod | grep bpf
• journalctl -k | grep -i verifier
• Check whether unprivileged BPF is enabled:
• sysctl kernel.unprivileged_bpf_disabled
• Check installed kernel package changelogs / vendor advisories for the CVE or the upstream commit IDs (distros already mapped this CVE into advisories such as Debian/Ubuntu trackers).

4) WSL2 and other Microsoft Linux kernels

• WSL2 runs a Microsoft‑maintained Linux kernel binary; Microsoft publishes the WSL2 kernel source and config publicly (the WSL2‑Linux‑Kernel repo). Whether a specific WSL kernel build includes the vulnerable code depends on the kernel version and config used for that WSL release; default WSL kernels may or may not include every kernel driver or context field. If you use WSL in your environment (or users do), check the shipped WSL kernel version and its build config.

5) Container images and Marketplace appliances

• Container base images generally don’t ship kernel code, but Marketplace VM images and appliances often do. For any Marketplace images you run, check the image’s kernel version and verify vendor advisories. If you run third‑party images on Azure that claim to be “Microsoft‑published” or “Azure‑optimized,” inspect them with image scanners (trivy, grype, dive, skopeo) or run the host checks above after provisioning.

Short‑term mitigations while you patch

• For hosts where you cannot patch immediately:
• Disable unprivileged BPF loads: echo 1 > /proc/sys/kernel/unprivileged_bpf_disabled (or set via sysctl). This reduces the attack surface for many of these verifier‑correctness issues because they are triggered by loading crafted eBPF programs.
• Ensure only trusted accounts hold CAP_BPF/CAP_SYS_ADMIN capabilities.
• Harden multi‑tenant hosts: restrict who can load BPF programs, restrict container runtimes from exposing privileged capabilities, and review CI runners and developer workstations where unprivileged loads may be allowed.
• Monitor kernel logs for verifier warnings, OOPS traces, and the exact conversion error strings that public trackers documented for this CVE.

Operational guidance for security teams (how to prioritize)

• Priority 1: Patch and validate Azure Linux images because Microsoft has attested that product as “potentially affected.” Apply Microsoft’s fixed images / kernel packages and validate the fix by checking changelogs and replaying representative eBPF workloads (or verifying the prior verifier warning/oops no longer appears).
• Priority 2: Inventory and validate any Microsoft images you actually run (Marketplace, AKS, WSL2, curated container base images). Don’t assume safety from absence in VEX; confirm by inspecting artifacts or waiting for Microsoft’s attestation updates for additional products.
• Priority 3: For any Linux hosts (Microsoft‑or‑not) that allow untrusted BPF program loads or run eBPF‑heavy agents (Cilium, Falco, observability stacks), prioritize patching because the practical attack vector is local program loading and the impact is availability/stability.

What to watch for from Microsoft (and how to consume their attestations)

• Microsoft’s MSRC advisory and their VEX/CSAF outputs are the vendor’s authoritative inventory statements; they will update those documents as they expand their mapping to additional products. If you rely on Microsoft artifacts, subscribe to MSRC updates and to Microsoft’s VEX/CSAF feed so you’re notified when a product changes state (Known‑Affected → Fixed / Not‑Affected).
• Do not treat “not listed yet” as “not affected.” If you run a Microsoft artifact that hasn’t been attested for this CVE, treat it as “unknown” until verified either by Microsoft’s updated attestation or your artifact inspection.

References and evidence (authoritative trackers)

• Upstream and distributor trackers (NVD, Ubuntu, Debian, SUSE) catalogue CVE‑2025‑38591, the technical description, and which kernel commits and package versions include the fix. These are the canonical places to map a kernel package to a CVE and find fixed package versions for distros.
• Microsoft’s MSRC advisory for CVE‑2025‑38591 explicitly states Azure Linux includes the implicated open‑source component and that the company began publishing machine‑readable VEX/CSAF attestations beginning October 2025; Microsoft says it will update the CVE if more Microsoft products are discovered to include the component. That is the product‑scope attestation described above.

Concise operational checklist you can copy

• If you run Azure Linux: apply Microsoft’s Azure Linux kernel updates now.
• Inventory Microsoft images you run (Marketplace, AKS nodes, WSL2, curated images). For each, check kernel version/config and vendor advisories.
• For unpatched hosts, set kernel.unprivileged_bpf_disabled = 1 and restrict CAP_BPF.
• Monitor kernel logs for verifier warnings and OOPS messages (alert on those strings).
• Subscribe to MSRC / VEX/CSAF updates and vendor distro advisories; re‑scan your artifacts when Microsoft expands attestations.

Bottom line

• Microsoft’s public wording for CVE‑2025‑38591 means Azure Linux is the only Microsoft product Microsoft has confirmed (so far) to include the vulnerable upstream kernel code; that attestation is authoritative for Azure Linux.
• However, that product‑level attestation is not proof other Microsoft artifacts cannot include the same upstream code — those artifacts remain potential carriers until they are inventoried and attested or until you verify them yourself. Act on Microsoft’s Azure Linux signal immediately, and verify other Microsoft images and kernels you run.

If you’d like, I can:

• Produce a short, copy‑pasteable runbook (commands + prioritized checklist) tailored to the exact Microsoft artifacts or Azure subscriptions you run.
• Help parse a specific image or kernel you give me (kernel version, /boot/config, or image name) and tell you whether it likely contains the vulnerable code and how to remediate it.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center