CVE-2025-38502: Azure Linux BPF Risk and Microsoft Product Exposure

Microsoft’s public attestation that Azure Linux includes the vulnerable Linux BPF component behind CVE‑2025‑38502 is accurate — but it is not a blanket assurance that Azure Linux is the only Microsoft product that could carry the same vulnerable upstream code.

Background / Overview​

CVE‑2025‑38502 is a Linux kernel vulnerability in the BPF (eBPF) subsystem that permits an out‑of‑bounds (OOB) access in cgroup local storage when certain tail‑call scenarios occur. In short, when two BPF programs with different local‑storage value sizes are linked by a tail call, the runtime context can cause the callee to read or write against the caller’s storage layout. That mismatch can be abused to cause memory corruption and kernel instability. The bug was introduced around Linux 5.9 and was fixed in later stable kernels; the upstream fixes were applied in the 6.16.1 and 6.17 development branches.
This is a local, low‑to‑medium impact vulnerability in typical vendor severity mappings: it requires BPF program execution and specific cgroup local storage usage to trigger, and exploitation typically requires either privileges to load or manipulate eBPF programs or permissive system configuration (for example, where unprivileged BPF use is allowed in containers or developer machines).
Microsoft’s security advisory explicitly states that Azure Linux — Microsoft’s maintained Linux distribution lineage used for Azure VM images — “includes this open‑source library and is therefore potentially affected,” and that the company will update the CVE attestations if more Microsoft products are found to ship the same upstream component. That phrasing reflects a product‑by‑product inventory process and an initial, conservative attestation; it is not a definitive statement that other Microsoft artifacts are safe.

---

Technical anatomy of CVE‑2025‑38502​

What the bug is and how it happens​

• The vulnerability stems from the BPF cgroup local storage implementation and how the kernel runtime resolves the storage pointer in a tail‑call stack.
• When Program A (with local storage value size X) tail‑calls Program B (which expects local storage value size Y), the runtime may still reference Program A’s storage descriptor for Program B, producing a size mismatch and potential out‑of‑bounds accesses.
• The BPF verifier accepts each program independently; verification succeeds because it does not see the inter‑program mismatch created at runtime by the tail call linkage.
• The specific code paths touched are in kernel BPF core runtime routines and BPF local storage helpers that resolve per‑program or per‑CPU buffers.

Affected kernel range and fixes​

• The problematic code path was introduced in the 5.9 kernel tree (therefore kernels built from that code line onward are candidates) and was addressed in later stable kernels.
• The upstream bugfix was merged into the stable stream; canonical fixes were applied in the 6.16.1 stable release and in the 6.17 development branch.
• Many Linux distributors map the upstream commits into their own kernel packages and backport fixes to older stable kernels; therefore, vulnerability presence is a function of kernel version plus vendor backport policy and configuration, not solely of kernel version number.

Exploitation prerequisites and attack surface​

• Attack vector: Local — a local process must be able to execute or load BPF programs that use cgroup local storage and chain tail calls as required by the exploit pattern.
• Privileges: typically low privileges are sufficient if the kernel permits unprivileged BPF loading or if the process/container has CAP_BPF or CAP_SYS_ADMIN (or delegated BPF tokens in newer kernels). Many hardened vendor kernels default to disabling unprivileged BPF by sysctl or Kconfig, but this varies by distribution and kernel build.
• Impact: availability‑first (kernel OOPS/panic or memory corruption). Some vendor CVSS mappings classify it as moderate/medium because confidentiality and integrity impact are limited, but availability (host crash or denial of service) can be significant on shared infrastructure.

---

Is Azure Linux the only Microsoft product that includes the vulnerable library?​

Short answer: No (practical and technical nuance)​

Microsoft’s statement naming Azure Linux as including the implicated upstream component is a correct, verifiable attestation for that product family at the time the statement was published. However, it is a product‑level inventory statement, not a global exclusion of other Microsoft artifacts.
Technically and operationally, any Microsoft product or service that ships, distributes, or runs a Linux kernel build — or that supplies kernel images for VMs — could include the same vulnerable upstream code depending on the kernel version and configuration. Relevant Microsoft artifacts include, but are not limited to:

• Azure Linux images (confirmed attestation).
• Windows Subsystem for Linux (WSL/WSL2) kernels that Microsoft builds and distributes.
• Azure VM images and Azure Marketplace images that may package vendor kernels or Microsoft‑tuned kernels.
• Azure Kubernetes Service (AKS) node images or managed node images that use specific kernel artifacts.
• Container base images or prebuilt appliances maintained by Microsoft, if they include a kernel or kernel modules (less common, but possible for specialized images).
• Any Microsoft‑provided Linux kernel used for device services or developer tooling.

The presence (or absence) of the vulnerable code in each artifact depends on the specific kernel source, the configuration used to build the kernel, and whether the vendor backported the fix. Microsoft’s CSAF/VEX attestations — a welcome transparency step — are published incrementally; a product that is not yet listed simply means Microsoft has not completed inventory + attestation for that product, not that the product is guaranteed not to include the component.

Why Microsoft called out Azure Linux first​

• Azure Linux (the CBL‑Mariner / Azure‑tuned lineage) is Microsoft’s canonical Linux distribution for cloud images and is comparatively straightforward for the company to inventory and attest using CSAF/VEX.
• Large vendors typically phase attestation: start with the product families they maintain directly and expand to other artifacts as inventories complete.
• Microsoft stated a transparent workflow: it will update CVE product mappings if further internal inventories find the vulnerable upstream component in other products.

---

What this means for operators and security teams​

Treat Microsoft’s published Azure Linux attestation as a confirmed actionable alert for all environments that run Azure Linux images: prioritize patching or remediation on those images. For all other Microsoft artifacts, do not assume safety simply because a product is not listed — inventory and verification are required.
Below is a practical checklist and remediation runbook you can follow now.

---

Practical detection and triage runbook​

1. Inventory your Microsoft‑supplied Linux artifacts​

• Identify all places where Microsoft‑bundled or Microsoft‑maintained kernels might be running:
• Azure VM images (including Marketplace images).
• Azure Linux images (confirmed).
• WSL2 instances on developer machines and CI runners.
• AKS node images and managed node pools.
• Any Microsoft‑published appliance or image you consume.

2. For each host or image, collect kernel metadata​

Run these commands on each host or mount a VM image to check kernel artifacts:

• Check kernel release:
• uname -r
• Check exact kernel package version (distribution dependent):
• Debian/Ubuntu: apt policy linux-image-$(uname -r) or dpkg -l 'linux-image*'
• RHEL/CentOS/Oracle/SUSE: rpm -q kernel
• Inspect kernel config if available:
• zcat /proc/config.gz | grep -i bpf
• Or check /boot/config-$(uname -r)
• Look for BPF unprivileged sysctl setting:
• sysctl kernel.unprivileged_bpf_disabled
• sysctl net.core.bpf_jit_enable
• Inspect installed WSL kernel version on Windows machines:
• In WSL: uname -r
• On Windows: wsl --status or wsl --version; check if custom kernel is configured in %USERPROFILE%.wslconfig

3. Map package versions to vendor advisories​

• For each kernel package/version you found, consult the distributor security advisory or Microsoft CSAF/VEX output for that product to determine whether the fixed upstream commit was included or backported.
• If vendor mapping is unclear, assume the host is potentially vulnerable until you can confirm the presence of the specific upstream fix.

4. Check for BPF workload presence in production​

• Identify processes that load or manage eBPF programs (observability tools, networking agents, custom daemons).
• Use bpftool (if available) to list programs:
• bpftool prog show
• Check audit logs or tooling for recent bpf syscalls or verifier rejections.

5. Immediate mitigations if patching is delayed​

• Disable unprivileged BPF on production hosts:
• sysctl -w kernel.unprivileged_bpf_disabled=1
• Persist via /etc/sysctl.d/90-disable-unpriv-bpf.conf
• Reduce capability exposure in containerized environments:
• Avoid granting CAP_BPF or CAP_SYS_ADMIN to containers.
• For container runtimes, set default capability drops and only allow required ones to specific trusted images.
• Isolate CI/build machines and developer hosts that run third‑party or untrusted BPF code.
• Add detection: alert on kernel OOPS, repeated verifier warnings in dmesg, or bpftool program loads from untrusted users.

---

Patching and remediation guidance​

• Prioritize applying vendor patches that include the upstream fix (the definitive remediation). Reboot into the patched kernel after installing the package.
• For Azure Linux images: apply Microsoft’s kernel updates or consume updated Azure VM images as Microsoft publishes CSAF/VEX attestations and advisories.
• For WSL2:
• Microsoft publishes WSL2 kernel sources and prebuilt kernel updates; update WSL via the package mechanism (Microsoft provides WSL updates independently of Windows build).
• If you run a custom WSL kernel, rebuild it against the patched upstream commits or switch to Microsoft’s updated WSL kernel.
• For Kubernetes/AKS node pools: coordinate node image updates or drain/recreate nodes once updated node images or kernel packages are available.
• If vendor backports are not available, evaluate the feasibility of applying the upstream commit patch to your kernel builds (requires kernel expertise and testing).

---

Strengths and benefits of Microsoft’s CSAF/VEX attestation approach — and the risks​

Strengths​

• Machine‑readable attestations (CSAF/VEX) let enterprise tooling automate triage and remediation decisions for Microsoft‑attested products.
• Publishing product‑level mappings increases transparency and reduces ambiguity for customers consuming Microsoft images.
• Targeting Azure Linux first is practical: it’s a Microsoft‑maintained distro where vendor‑side inventory is simpler and quicker to publish.

Potential risks and gaps​

• Attestation scope can be mistaken for exhaustiveness: customers may assume that unlisted Microsoft products are safe. That assumption is unsafe when vendors roll out attestations in phases.
• Multiple Microsoft kernel artifacts exist (WSL2 kernels, image pipelines, Marketplace images), and each requires separate inventory verification; customers must not rely solely on a single attestation.
• Operational complexity for customers: teams must correlate vendor attestations with their own inventories, kernel versions, and container/capability policies — that remains a nontrivial engineering effort.
• Timing: phased inventory means a window where artifacts haven’t been audited and might still be vulnerable but not yet listed.

---

Recommended policy and governance changes for enterprises​

• Adopt an inventory‑first playbook that treats vendor attestations as partial signals; perform your own artifact and kernel scans across the fleet.
• Automate kernel package/version collection and map those to vendor advisories (use vendor CVE to package mappings).
• Enforce conservative capability posture in container platforms: deny by default, permit CAP_BPF and CAP_SYS_ADMIN only for explicitly approved images and workloads.
• Add kernel‑level sysctl hardening (disable unprivileged BPF) in multi‑tenant or sensitive environments.
• Expand vendor expectations in procurement and SLAs: require timely CSAF/VEX coverage for all vendor‑shipped OS images and kernel artifacts that customers consume.

---

Conclusion​

Microsoft’s MSRC statement that Azure Linux includes the open‑source component implicated in CVE‑2025‑38502 is an important, actionable signal and should be treated as such: Azure Linux images are confirmed carriers and must be patched or updated per Microsoft’s advisories. However, that statement does not mean Azure Linux is the only Microsoft product that could contain the vulnerable upstream code.
Any Microsoft product or service that ships or manages Linux kernel builds — most notably WSL2 kernels, Azure VM image kernels, AKS node images, and other Microsoft‑supplied kernel artifacts — should be verified on a per‑artifact basis. The correct operational stance for security teams is to assume potential exposure where Microsoft has not yet completed attestations, inventory aggressively, apply vendor patches promptly, and use compensating controls (disable unprivileged BPF, limit CAP_BPF/CAP_SYS_ADMIN) while waiting for vendor updates.
This vulnerability is a reminder that large vendors now publish machine‑readable attestations and that those attestations are a powerful tool when combined with disciplined, automated inventory, capability‑management policies, and rapid patching.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center