Microsoft’s short advisory that “Azure Linux includes this open‑source library and is therefore potentially affected” is accurate for the Azure Linux product family, but it is a
product‑scoped attestation — not a categorical statement that no other Microsoft product can include the same vulnerable code. Azure Linux is the only Microsoft product Microsoft has publicly attested (so far) to include the specific upstream code mapped to CVE‑2025‑39990; however, any Microsoft artifact that ships or runs a Linux kernel build could still be a carrier until it is checked and attested or independently verified.
Background / Overview
CVE‑2025‑39990 is a Linux kernel BPF verifier correctness fix described in the downstream trackers and the upstream kernel commits as “bpf: Check the helper function is valid in get_helper_proto.” The defect was identified by automated kernel test tooling and arises where a BPF helper function pointer could be NULL if certain kernel configuration options are disabled; the upstream change makes get_helper_proto validate helper pointers and marks unused helpers appropriately to avoid NULL dereferences or verifier inconsistencies. Public trackers describe the impact as a verifier bug with local vectors and availability/robustness implications rather than an obvious remote RCE. Multiple independent trackers (NVD/OSV/Ubuntu/Debian) catalog the vulnerability, map the upstream fixes to stable kernel commits, and list distribution package status and fixes. These authoritative vendor and distro pages corroborate the technical description that the fix is a defensive verifier correctness change merged into the stable kernel trees.
What Microsoft actually published — and what it means
Microsoft’s Security Response Center (MSRC) published a concise product‑mapping statement saying that
“Azure Linux includes this open‑source library and is therefore potentially affected”, and it also explained that Microsoft began publishing machine‑readable CSAF/VEX attestations in October 2025 and will update CVE/VEX records if additional Microsoft products are identified as carriers of the same component. That blog post and the VEX rollout announcement make clear Microsoft’s approach is phased: start with Azure Linux (formerly CBL‑Mariner), publish deterministic, machine‑readable attestations for that product, then expand to other product families over time. Important distinction: Microsoft’s phrasing is
procedural and scoped. It reports what inventory work Microsoft completed for Azure Linux and what the company intends to do next. It is authoritative for the named product(s) in the VEX/CSAF feed, but it is not a universal guarantee that other Microsoft artifacts or product SKUs are free of the upstream code. That nuance is crucial for operational security teams.
Short answer to the user question
- No — Azure Linux is not necessarily the only Microsoft product that includes the open‑source library and is therefore potentially affected. It is the only Microsoft product Microsoft has publicly attested to include the implicated component for CVE‑2025‑39990 at the time of the MSRC advisory, but absence of attestation ≠ proof of absence. Treat Microsoft’s VEX/CSAF entry as authoritative only for the product it names.
Why the distinction matters — technical and operational context
- Product attestations are phased and product‑scoped.
- Microsoft explicitly started its CSAF/VEX rollout with Azure Linux to validate tooling and processes before expanding to many more SKUs. The VEX entries therefore reflect completed inventory work for Azure Linux, not the state of all Microsoft images or kernel builds.
- Different Microsoft artifacts are separate builds.
- Microsoft produces a range of Linux‑related artifacts — Azure Linux images, Azure‑tuned kernel packages (linux‑azure), WSL2 kernel binaries, curated Marketplace VM images, AKS node images, and partner Marketplace appliances. Each artifact is an independent build pipeline and may or may not include the same kernel commits or features depending on CONFIG_* flags, modules vs built‑in, and backport decisions. That means a vulnerability in upstream kernel code can exist in some artifacts and not in others.
- Carriers aren’t always obvious.
- A container image or VM image can inherit an older kernel or embed third‑party binaries compiled with vulnerable toolchains. Marketplace appliances and vendor images can contain unexpected components that escape a central attestation until explicitly inventoried.
- Vulnerability is in kernel code — the distribution of the kernel matters.
- Because CVE‑2025‑39990 is a kernel change, anything that ships a Linux kernel binary (WSL2 kernels, Azure VM kernels, linux‑azure packages, images) is in scope for inspection. A userland package that merely runs on top of the kernel would be affected only if the host kernel contains the vulnerable code.
Products and artifacts to check (practical list)
Organizations should assume potential exposure until proven otherwise for any Microsoft artifact that either ships or runs a Linux kernel. High‑priority surfaces to inventory and check include:
- Azure Linux distribution images (the product Microsoft attested). Apply MSRC guidance and the Azure Linux updates first.
- Linux kernels Microsoft ships for WSL2 — Microsoft builds and ships a WSL kernel and updates it through their servicing channels; verify your WSL kernel version and update flow.
- Azure Marketplace VM images and Microsoft‑curated VM images — these can include Azure‑tuned kernels or vendor kernels; check the kernel version and the image’s security tracker.
- AKS node images and managed node pools (node OS images and kernel packages) — managed Kubernetes images may use Microsoft-curated kernels in some SKUs.
- linux‑azure packages and any “azure‑tuned” kernel builds provided to guests — these are distinct artifacts that require their own verification.
- Marketplace appliances, partner images, and third‑party images hosted in Azure — these often escape centralized attestation and must be checked by the image owner.
- Custom images, container base images, and CI/CD runners that may have older snapshots or embedded kernel modules.
How to verify your exposure — a practical, prioritized runbook
- Prioritize assets
- Start with systems running Azure Linux images (MSRC attested product) and any hosts where multiple tenants or users can load eBPF programs. Then expand to WSL2, Azure VM SKUs, AKS nodes, and Marketplace images.
- Inventory and identify kernel versions
- On each Linux host check:
- uname -r
- Distribution kernel package version and package changelog (apt/yum/zypper)
- Match the kernel version or package changelog to the upstream commit referenced by CVE records (stable kernel commits listed in NVD/OSV).
- Consult vendor attestations and VEX/CSAF
- Consume Microsoft’s CSAF/VEX files for the CVE to see which product SKUs Microsoft has labeled Known Affected / Fixed / Not Affected / Under Investigation. For Azure Linux, the VEX entry is authoritative for that product. Use automation to consume the VEX files where possible.
- Check WSL2 kernel versions
- WSL2 uses a Microsoft‑maintained kernel image; check the WSL kernel version and apply the WSL kernel update flow if needed (Windows Update / wsl update flows). If you maintain custom WSL kernels, rebuild with patched sources.
- Inspect images and SBOMs
- Where possible, inspect image SBOMs or package manifests for kernel versions and kernel modules. For container images, check whether the host kernel or the image itself carries relevant binary components.
- Short‑term mitigations if you cannot patch immediately
- Where CVE impact is local and tied to eBPF program loading, reduce exposure by:
- Setting kernel.unprivileged_bpf_disabled = 1 to block unprivileged users from loading BPF programs (appropriate for multi‑tenant hosts).
- Restricting CAP_BPF, CAP_SYS_ADMIN capabilities to trusted accounts only.
- Auditing and restricting deployment of untrusted eBPF tooling (Cilium, Falco, XDP, tc filters, etc..
- Validate the remediation
- After patching, run representative eBPF workloads or the BPF selftests that previously triggered the problem and monitor kernel logs for verifier warnings or OOPS traces. Confirm the VEX/CSAF status flips to fixed for the relevant product images.
- Automate for scale
- Integrate VEX/CSAF consumption into your vulnerability management pipeline and combine it with image scanning, SBOM checks, and runtime telemetry to reach a high confidence posture. Microsoft’s VEX rollout is designed for automation, but the attestation must be interpreted in the context of your estate.
Why Microsoft’s approach is useful — and where it falls short
Strengths
- Deterministic, machine‑readable signals: Microsoft’s CSAF/VEX attestations provide clear, automatable statements for named products (e.g., Azure Linux), allowing security teams to reduce noisy false positives and make faster, targeted remediation decisions. This materially improves large‑scale triage automation.
- Visible, phased rollout: Starting with Azure Linux allowed Microsoft to pilot the process and validate automation before scaling to many products, which is a pragmatic approach when a vendor ships hundreds of distinct artifacts.
Risks and limitations
- Attestation lag and scope limits: VEX/CSAF entries are only as good as the inventory work completed. A single attestation covering Azure Linux does not guarantee other Microsoft images, kernels, or partner appliances are free of the same upstream code. Absence of an entry is absence of attestation, not proof of safety.
- Embedded and third‑party drift: Marketplace images, partner appliances, and layered container images can include older kernels or static artifacts that evade a central attestation. These are blind spots until inspected.
- Operational complexity for customers: Large customers manage thousands of images and hosts. Even with VEX/CSAF automation, artifacts downstream from a vendor image (custom builds, snapshots) require independent verification and remediation, which increases operational burden.
Concrete recommendations (prioritized)
- Patch Azure Linux hosts immediately.
- Microsoft’s VEX/CSAF attestation makes Azure Linux the highest‑confidence starting point; apply the vendor‑supplied update or replace affected images with Microsoft’s fixed images as directed.
- Inventory WSL and Azure VM kernel versions.
- Confirm WSL kernel versions and update via Microsoft’s documented servicing flow. Confirm Azure VM images and AKS node OS images use patched kernels.
- Automate VEX/CSAF consumption.
- Integrate Microsoft’s machine‑readable attestations into your vulnerability management and asset inventory pipeline. Use the VEX output to triage Azure Linux quickly, and treat other artifacts as “unverified” until confirmed by SBOM or package metadata.
- Apply short‑term operational mitigations where patching is delayed.
- Disable unprivileged BPF loading where appropriate, tighten capability grants, and restrict eBPF tool deployments on multi‑tenant or developer hosts.
- Verify fixes and monitor.
- After updating kernels, validate using representative workloads and selftests; monitor kernel logs for verifier warnings; alert on BPF‑related OOPS or traces.
- Expand inventory and SBOM coverage.
- Ensure image and artifact supply chains publish SBOMs and that your CI/CD processes prevent older kernels or third‑party artifacts from re‑entering production images. Treat the vendor attestation as an input to a broader supply‑chain verification program.
What we cannot prove from public data (caveats)
- A public VEX/CSAF attestation for Azure Linux does not reveal the internal state of every Microsoft image or kernel pipeline. Microsoft has committed to updating the CVE/VEX record if additional products are identified as carriers, but until that inventory work completes, there will necessarily be uncertainty about other Microsoft artifacts. Security teams should therefore adopt a conservative, evidence‑driven approach: verify artifacts you run rather than assuming attestation coverage extends beyond the named product.
- Public trackers and distributors list which kernel branches and package versions are patched, but mapping that to every image or appliance you run still requires artifact‑level checks (uname, package changelog, SBOMs). Those mappings are available from distro trackers (Ubuntu/Debian/OSV) and should be used to confirm remediation decisions.
Conclusion
Microsoft’s statement that
“Azure Linux includes this open‑source library and is therefore potentially affected” is an important and authoritative attestation — but it is intentionally scoped. Azure Linux is the
only Microsoft product explicitly attested for CVE‑2025‑39990 in Microsoft’s VEX/CSAF rollout so far, and that attestation is actionable: apply patches and treat Azure Linux hosts as highest priority. However, this does
not mean other Microsoft products are automatically safe; any Microsoft artifact that ships or runs a Linux kernel should be inventoried, verified, and patched as appropriate.
Operational teams should combine Microsoft’s VEX/CSAF output with artifact‑level checks (SBOMs, uname/package changelogs), short‑term mitigations (disable unprivileged BPF where appropriate), and automated consumption of vendor attestations to achieve assurance at scale. Treat the VEX statement as a clear starting point — not the final word — and keep an eye on Microsoft’s VEX updates as their phased inventory work expands to additional products.
Source: MSRC
Security Update Guide - Microsoft Security Response Center