The Linux kernel patch tracked as CVE-2025-39886 fixes a subtle BPF (eBPF) allocation and locking interaction — specifically, telling memcg to take the
allow_spinning=false path in bpf_timer_init so that memcg accounting does not trigger recursive notifications while a raw spinlock or other atomic context is held. Microsoft’s MSRC advisory explicitly calls out
Azure Linux as a product that “includes this open‑source library and is therefore potentially affected,” and the company has said it will expand its machine‑readable CSAF/VEX attestations if additional Microsoft products are found to ship the same upstream component. That MSRC wording is a product‑level attestation, not a definitive statement that
no other Microsoft product can include the same kernel code — in practical terms, Azure Linux is the only Microsoft product Microsoft has inventory‑checked and attested so far, but other Microsoft‑distributed kernels or images (notably the WSL2 kernel and CBL‑Mariner lineage artifacts) are plausible carriers and must be verified by artifact inspection.
Background / Overview
CVE-2025-39886 is an upstream Linux kernel correctness/fix issue in the BPF subsystem. The underlying symptom arises when a BPF timer cancellation path triggers memcg accounting under an atomic/locked context, which can cause double-locking or ordering violations (lockdep warnings, kernel BUGs) in
PREEMPT_RT or otherwise-sensitive kernels. The upstream corrective change changes allocation flags (using __GFP_HIGH instead of GFP_ATOMIC in the async path) and ensures memcg is told to take the
allow_spinning=false path so that notifications (like cgroup_file_notify) that may acquire other locks are avoided while atomic locks are held. This is a robustness/availability fix, not a confirmed remote code execution or data‑exfiltration issue, but it can cause kernel lockups or crashes on affected builds. Major distribution trackers (NVD, Ubuntu, SUSE) and the kernel stable trees have recorded the CVE, the implicated files (kernel/bpf helpers), and the upstream commits that implement the fix. Those vendor pages are the best sources for mapping fixed commits to distribution package versions.
Why the MSRC wording matters — product attestation vs. absolute exclusion
Microsoft’s phrasing — “Azure Linux includes this open‑source library and is therefore potentially affected by this vulnerability” — is intentionally narrow and procedural. It means Microsoft completed an inventory for the Azure Linux product family and confirmed the component appears in those images; Microsoft then published a CSAF/VEX attestation indicating Azure Linux should be treated as in‑scope for remediation. That attestation is authoritative for Azure Linux, and customers running those Microsoft‑published images should treat Azure Linux as confirmed potential carriers and remediate per Microsoft guidance.
Crucially, the attestation is a snapshot of Microsoft’s inventory work at publication time. It does
not prove that other Microsoft products (WSL2 kernel images shipped with Windows, CBL‑Mariner lineage images, linux‑azure kernels used in Marketplace images, or other Microsoft‑distributed kernels) are free of the same upstream code. Because the Linux kernel is a build‑time artifact — the same upstream source can appear in multiple binary artifacts depending on kernel version, chosen config options, and backports — defenders must not assume “no mention = not vulnerable.” Instead, treat the MSRC attestation as a positive confirmation for Azure Linux and a prompt to perform artifact‑level verification for any other Microsoft artifacts you run.
Is Azure Linux the only Microsoft product that includes the library and is therefore potentially affected?
Short answer: No — Azure Linux is the only Microsoft product Microsoft has publicly attested to include the implicated upstream code
so far, but that does not guarantee it is the only Microsoft artifact that could carry the vulnerable kernel code.
Why:
- Microsoft’s attestation model exposes which product families it has inventory‑checked and mapped into CSAF/VEX. Azure Linux appears first in that rollout, which is why MSRC names it. That makes Azure Linux a confirmed hit for immediate remediation.
- Microsoft also builds and distributes other Linux kernel artifacts — most importantly the WSL2 kernel (published in the microsoft/WSL2‑Linux‑Kernel GitHub repository and delivered via Microsoft Update), and internal distributions / build artifacts such as CBL‑Mariner and linux‑azure kernels used for various cloud images. If those kernels were built from upstream sources that contain the vulnerable commit range and the kernel configuration compiled the implicated BPF code paths into the kernel, they too could be affected.
- Microsoft has said it will update its CVE/VEX records if further Microsoft product artifacts are identified as carriers of the same upstream component; until such attestations appear, the status of other Microsoft artifacts remains unverified, not conclusively negative.
In practical operational language: treat Azure Linux as confirmed-in-scope; treat other Microsoft‑provided kernels (WSL2 kernel, CBL‑Mariner derivatives, Marketplace or image kernels) as
potentially in‑scope until you or Microsoft verify otherwise.
Technical impact and who should worry first
This CVE’s primary operational impact is
availability (kernel BUG/lockup) rather than confidentiality or integrity, and the exploitability and observed impact depend on build and policy details:
- The issue manifests primarily in kernels that can exercise the problematic BPF timer cancellation path while holding locks (e.g., PREEMPT_RT or specific kernel configs that enable BPF timer workflows). Many general‑purpose distros running standard non‑RT kernels are less likely to trigger the exact conditions, but kernels built with real-time patches or unusual configurations can be exposed.
- Attack vector is local: an attacker or untrusted workload would generally need the ability to load or cause a BPF program that exercises the timer path. Whether unprivileged users can load such programs depends on kernel policy knobs (for example kernel.unprivileged_bpf_disabled or distribution defaults).
- The most at‑risk environments:
- Multi‑tenant hosts and cloud hypervisors where tenant workloads or containers might load BPF programs.
- Systems heavily reliant on eBPF for networking/observability (Cilium, XDP, Falco, high-performance dataplane stacks).
- Real‑time or embedded systems that use PREEMPT_RT kernels.
For these reasons, operations teams should prioritize hosts that run eBPF workloads and any Microsoft‑supplied images or kernel artifacts you operate (including WSL kernel on Windows hosts used for development or CI), and treat Azure Linux images as a top priority because of Microsoft’s explicit attestation.
Concrete verification checklist (artifact‑level checks)
Perform these artifact checks immediately across your estate — they are short, automatable commands that detect whether a particular image or kernel is plausibly affected:
- Identify kernels and images in use:
- Linux VMs and container hosts: run uname -r and capture kernel package versions.
- WSL2 instances: check the WSL kernel version via wsl --status and validate against microsoft/WSL2‑Linux‑Kernel tags. Microsoft publishes the WSL2 kernel source and release notes; if your deployed WSL kernel predates the fix, it may need update.
- Marketplace images/custom appliances: boot a test instance and run the same checks (uname -r, kernel package metadata).
- Confirm kernel configuration and BPF presence:
- zgrep CONFIG_BPF /boot/config-$(uname -r) (or check /proc/config.gz if present). If BPF is built in or modules are present, the host is a candidate for exposure.
- lsmod | grep bpf to see if BPF modules are loaded.
- For PREEMPT_RT: grep PREEMPT /boot/config-$(uname -r) or zgrep PREEMPT /proc/config.gz to see if real‑time patches or CONFIG_PREEMPT_RT are enabled. Many vendor advisories show PREEMPT_RT as a significant exposure factor.
- Search for vendor package mappings:
- Use your distribution’s security tracker / package manager changelog to match your kernel package to the upstream commit IDs referenced in vendor advisories (NVD, Ubuntu USN, SUSE advisories contain these mappings). Updating to the patched package is the definitive remediation.
- Inspect Microsoft product artifacts you run:
- If you run Azure Linux images, follow Microsoft’s guidance and patch/reboot per its Azure Linux advisories — MSRC’s attestation makes that product definitely in‑scope.
- If you run WSL2 on Windows hosts, inspect the local deployed WSL kernel and, if necessary, update via Windows Update or the WSL kernel releases. Microsoft publishes WSL kernel sources and release notes; those provide the version mapping you need.
Use automation to ingest Microsoft’s CSAF/VEX attestations (MSRC now publishes machine‑readable VEX metadata) — that will give you definitive product mappings as Microsoft expands its attestation coverage.
Remediation and mitigations (practical playbook)
The only fully reliable remediation is to install vendor‑supplied kernel updates (or rebuilt image bundles) that include the upstream fix and reboot into the patched kernel. For managed Azure Linux images, follow Microsoft’s update guidance and apply the patched kernel image. Short‑term mitigations to reduce risk until patches are applied:
- Disable unprivileged BPF where feasible:
- sysctl -w kernel.unprivileged_bpf_disabled=1
- Persist the change via your configuration management if appropriate.
- This reduces the chance that non‑privileged workloads can load the BPF programs required to trigger the path.
- Restrict capabilities:
- Ensure only trusted accounts or container images have CAP_BPF or CAP_SYS_ADMIN.
- Audit container runtime and service accounts to minimize the set of actors that can load BPF programs.
- Shorten attack surface:
- Limit deployment of third‑party BPF toolchains and untrusted eBPF programs on production nodes.
- Harden container runtime policies: use seccomp, AppArmor, SELinux to block untrusted syscalls and limit device exposure.
- Monitor kernel telemetry:
- Watch for dmesg / journalctl -k traces for lockdep / BUG messages referencing BPF timer paths, bpf_map_kmalloc_node, or memcg events. Repeated kernel OOPSes tied to BPF activity are a high‑priority signal.
Plan the patch rollout in waves: pilot → expanded → production. After patching, validate the kernel version and absence of the previous OOPS patterns for at least a week in production telemetry.
Cross‑checking Microsoft’s message and independent confirmation
Multiple independent trackers (NVD, Ubuntu, SUSE) and the upstream kernel commits corroborate the vulnerability description and the upstream fix details; that provides the cross‑validation required to be confident in the technical facts. The NVD entry and Ubuntu bulletin summarize the same stack traces and the same fix rationale: avoid spinning notifications during memcg accounting by using allocation flags that cause memcg to run the
allow_spinning=false path, avoiding recursive notifications that acquire other locks. On the Microsoft side, the MSRC advisory’s wording and Microsoft’s public CSAF/VEX rollout approach are consistent with modern vendor practices: publish attestations for product families you have inventory‑checked and expand coverage over time. That is why Azure Linux is explicitly named while other Microsoft kernels remain “unverified” until Microsoft’s inventory discovers and maps them. This distinction — attestation vs. universal exclusion — is critical for defenders to understand.
Notable strengths and potential risks in Microsoft’s approach
Strengths:
- Publishing CSAF/VEX attestations improves transparency and gives customers an authoritative, machine‑readable signal they can ingest into automation. Microsoft’s decision to start with Azure Linux creates a clear, actionable signal for a critical product family.
- Microsoft publishes and maintains the WSL2 kernel source, enabling customers to inspect versions and configuration, which aids rapid artifact verification.
Risks / limitations:
- Attestation is a snapshot: absence of an attestation for a Microsoft product is not proof that the product is unaffected. Customers who rely solely on “attested vs not‑attested” lists risk missing vulnerable artifacts in their estate. Artifact‑level verification remains essential.
- The kernel is a distributed, forked, and backported codebase. Even if an attestation is eventually published, customers must still validate that the specific deployed kernel binary (its version, backports, and config) has the patch applied. Vendor-side attestations aid automation but do not replace local verification.
Operational checklist (quick, prioritized)
- Patch Azure Linux images first — Microsoft has attested them as potentially affected. Reboot nodes after applying the patched kernel.
- Inventory other Microsoft artifacts you run (WSL, Marketplace images, CBL‑Mariner lineage) and perform the artifact‑level checks described above (uname, kernel config, module presence). Automate this where possible.
- If you cannot immediately patch, set kernel.unprivileged_bpf_disabled=1 and audit CAP_BPF / CAP_SYS_ADMIN grants.
- Track vendor advisories (NVD, Ubuntu, SUSE, Microsoft MSRC) for package-to-commit mappings and apply vendor packages that include the upstream commits. Validate by checking kernel package changelogs for the referenced commits.
- Ingest Microsoft’s CSAF/VEX output into your vulnerability tooling so you automatically learn when Microsoft expands its attestations beyond Azure Linux.
Final verdict and cautionary note
Microsoft’s public statement that “Azure Linux includes this open‑source library and is therefore potentially affected” is accurate and actionable: Azure Linux is the
confirmed Microsoft product in scope for CVE‑2025‑39886 at publication time. However,
it is not a proof that no other Microsoft products include the vulnerable kernel code. Any Microsoft artifact that ships a Linux kernel built from upstream source containing the vulnerable commits and with the relevant BPF options enabled could be affected. Customers must therefore combine Microsoft’s attestation signal with artifact‑level verification (kernel version, configuration, module list, package changelogs) across their estate.
If you operate Azure Linux images, prioritize Microsoft’s Azure Linux guidance and patch those images immediately. If you operate any other Microsoft‑supplied Linux artifacts — especially WSL2 kernels, CBL‑Mariner or linux‑azure images, or Marketplace images — perform the verification checklist above and treat unverified artifacts as potentially affected until proven otherwise. Automation that ingests vendor CSAF/VEX attestations and ties them back to deployed artifacts will reduce uncertainty as Microsoft expands its attestations.
Every remediation decision should be driven by the artifact-level evidence you collect: kernel version, vendor package mapping, kernel config, and module presence. MSRC’s attestation for Azure Linux is an authoritative starting point; it does not relieve defenders from verifying the other Microsoft artifacts they run. The recommended playbook is straightforward: inventory, verify, patch, and harden — and automate CSAF/VEX ingestion so the next attestation arrives in your tooling as soon as Microsoft publishes it.
Source: MSRC
Security Update Guide - Microsoft Security Response Center