CVE-2025-38704 Explained: Azure Linux Attestation and RCU NOCB Risk

Microsoft’s advisory for CVE-2025-38704 names Azure Linux as the Microsoft product that “includes this open‑source library and is therefore potentially affected,” but that product‑level attestation is an inventory statement — not a technical guarantee that no other Microsoft image, kernel, or runtime can contain the same vulnerable rcu/nocb code path.

Background / Overview​

CVE‑2025‑38704 is a Linux kernel vulnerability in the RCU nocb (No Callback) code that could cause an invalid pointer access of rdp->nocb_cb_kthread during certain CPU online/offline and kthread operations. The bug is a correctness/race condition in the kernel’s nocb logic and has been fixed upstream in stable kernel trees (for example, fixed in 6.12.43 and in backports to other stable branches). Upstream advisories and distribution trackers describe the defect, identify the commit diffs that address it, and classify the practical impact as availability / crash‑type behavior rather than remote code execution. Major Linux distribution security trackers (Debian, Ubuntu, SUSE, Amazon Linux) and the kernel CVE announcement list the same technical summary and the same upstream commit IDs that implement the change. These independent trackers also show which packaged kernels are vulnerable and which contain the backport. That mapping is the authoritative technical record you should use to decide whether a given kernel/build in your estate is vulnerable. Microsoft’s public advisory language on the issue — the wording quoted by many readers — follows the company’s product‑scoped VEX/CSAF model: Microsoft has published machine‑readable component attestations for the Azure Linux distribution and explicitly states it will update the CVE record if it identifies impact in additional Microsoft products. That phrasing is a declarative inventory result for Azure Linux, not a technical assertion that other Microsoft artifacts are impossible vectors for the same upstream code.

---

What CVE‑2025‑38704 actually is (technical summary)​

• Affected subsystem: Linux kernel — rcu/nocb.
• Fault class: possible invalid pointer access (kthread pointer) caused by a race in CPU onlining/offlining and rcuop kthread creation/de‑offload logic.
• Symptom when triggered: kernel oops, NULL‑pointer access, or panic — an availability impact (system instability or crash).
• Fix pattern: change safety check to use rdp->nocb_gp_kthread (gp kthread pointer) instead of the potentially unset rdp->nocb_cb_kthread, with upstream commits landed in stable kernel releases.

Why this matters operationally: the bug is not a straight‑line remote code execution. Instead, it creates a local crash vector that can be weaponized in shared or multi‑tenant environments where an unprivileged or low‑privileged user can exercise CPU onlining/offlining or other kernel paths that interact with nocb state. The practical focus for defenders is kernel stability telemetry and a timely patch rather than network IDS signatures.

---

How to read Microsoft’s wording — “Azure Linux includes this open‑source library and is therefore potentially affected”​

Microsoft’s statement should be read as a product‑level inventory attestation: the company has completed an internal component mapping for the Azure Linux distribution and published that finding via CSAF/VEX. That means:

• For Azure Linux customers, the statement is authoritative: Microsoft has identified the vulnerable kernel component in that distribution and has published the product’s status and remediation plan.
• For other Microsoft products (WSL2 kernel, marketplace VM images, curated container images, AKS node images, appliance/Edge offerings, Azure Marketplace partner images, etc., Microsoft’s statement is silent by omission rather than an affirmative “not affected” declaration. The company has committed to update the CVE/VEX record if further Microsoft products are found to ship the component, which is a procedural assurance but not an instantaneous inventory sweep of every Microsoft artifact.

Put another way: the published VEX/CSAF attestation reduces uncertainty for Azure Linux customers by saying “we’ve checked this product and here’s its status.” It does not automatically prove other Microsoft products do not ship the same upstream code — because inclusion is a per‑artifact, build‑time property.

---

Is Azure Linux the only Microsoft product that includes the rcu/nocb component?​

Short answer: No — Azure Linux is the only Microsoft product that Microsoft has publicly attested (via VEX/CSAF) to include the vulnerable rcu/nocb component so far, but that is not a technical proof of exclusivity. Other Microsoft artifacts could include the same kernel code depending on how those artifacts are built and packaged. The vendor’s published attestation is a starting point for triage; it is not a universal safety certificate for the rest of Microsoft’s product surface.
Why this distinction matters (technical reasons):

• Kernel features are enabled or disabled at build time (CONFIG_* flags). Whether a given Microsoft image or product includes the nocb code depends on the kernel configuration used when that kernel was built. Different Microsoft artifacts (Azure Linux, linux‑azure packages, WSL2 kernel, AKS node images, Marketplace images) may be built from different kernel trees, different configs, and therefore may differ in component presence.
• Microsoft and partners ship many independent artifacts: curated containers for Azure ML, Databricks runtime images, marketplace VM images, device/edge firmware, appliance images and custom WSL kernels. Each is an independent inventory target; a single product attestation does not automatically propagate to all of them.
• Long‑tail and third‑party images: marketplace or partner images hosted on Azure can embed older or differently‑patched kernels. Those images are not covered by the Microsoft Azure Linux attestation unless Microsoft explicitly includes them in a VEX/CSAF mapping.

Therefore, from an operational perspective, treat Microsoft’s Azure Linux attestation as an authoritative signal for Azure Linux only. For other Microsoft‑provided or Microsoft‑hosted artifacts you use, you should confirm presence/absence with the steps below.

---

How to verify whether a Microsoft product or image you run is affected​

The only reliable method to determine exposure is per‑artifact verification — inspect the kernel version/config or the packaged kernel changelog and verify whether the upstream fix/commit is present. The following checklist is a practical triage playbook.

1. Inventory and discovery (high priority)​

• Enumerate Microsoft‑published images and artifacts in your estate:
• Azure Linux images (official Microsoft images).
• Marketplace VM images and partner images used in your environment.
• AKS node image versions and AKS node pools.
• WSL2 kernel versions in use on Windows hosts (check the WSL2 kernel package or the published WSL kernel repo if you use a Microsoft‑provided kernel).
• Curated container images (Azure ML, Databricks runtimes, curated ML environments) that you consume.
• Inventory private registries and any cached or snapshot images that may contain older kernels or vendor packaging.

2. Verify kernel version and patch presence​

• On a suspect Linux host or image, run:
• uname -r
• cat /boot/config-$(uname -r) (or /proc/config.gz) to confirm kernel config flags.
• Search the kernel source package/changelog or the distribution advisory to see whether the upstream fix commit(s) appear in the package changelog.
• Look for the specific upstream commits that fixed CVE‑2025‑38704:
• Fixed in 6.12.43: commit cce3d027227c...
• Fixed in other stable backports: 1c951683a7..., 9b5ec8e6b3..., 1bba3900ca...
• Use grep against your packaged kernel source to find those commits or the modified file kernel/rcu/tree_nocb.h.

3. For images (VMs/containers) and immutable artifacts​

• Appliances, VM images, container images and cached snapshots must be inspected by mounting the image and checking the packaged kernel binary / kernel config, or by running the image and performing the checks above.
• Statically packaged kernels in appliances require vendor updates — a distribution package update is insufficient if the image uses a baked‑in kernel binary.

4. WSL2, AKS, and cloud-managed surfaces​

• WSL2: Microsoft publishes the WSL2 kernel repo and configuration. Check the kernel version shipped by Microsoft or any custom WSL kernels you built. If you use the Microsoft‑provided WSL kernel, confirm it contains the upstream fix (or that Microsoft’s WSL kernel package has been updated).
• AKS & managed node images: check node image versions and the image manifest for kernel version mapping. Managed control planes may be updated independently of node images — inspect node pools for the exact kernel version in use.

5. Detection and telemetry​

• Watch for kernel oops traces referencing nocb or rcu tree_nocb code in dmesg/journalctl -k. Kernel crashes may reboot hosts and erase ephemeral traces; ensure persistent journal and crashdump/kdump capture is enabled.
• Hunt for patterns around CPU online/offline operations correlated with unexpected kthread_unpark traces or stack traces referencing the modified file.

---

Recommended remediation and prioritization​

• Patch priority: treat systems that run shared, multi‑tenant workloads, hypervisor hosts, or services where untrusted workloads run as highest priority. For single‑tenant, fully controlled desktops the urgency is lower, but patching is still recommended.
• Apply vendor patches: install the distribution or vendor kernel package that lists CVE‑2025‑38704 in its changelog or security advisory. For Azure Linux customers, follow Microsoft’s Azure Linux update guidance tied to its VEX/CSAF attestations.
• Test and roll: kernel updates require reboots and testing. Use a staged rollout and verify crashdump and logging capture before broad deployment.
• For immutable images: rebuild or replace affected VM/container/appliance images with patched kernels; do not rely on host OS patching alone if the artifact contains its own kernel.
• Compensating controls if patching is delayed:
• Restrict untrusted/local access to hosts that can exercise the relevant CPU online/offline paths.
• Harden container isolation and limit the ability of unprivileged containers to manipulate CPU affinity or CPU hotplug operations.
• For managed services, follow vendor guidance on image replacement or node pool upgrades.

---

Why Azure Linux being named does not mean “only Azure Linux” — a deeper operational analysis​

Microsoft used the Azure Linux product family as the first beneficiary of its machine‑readable VEX/CSAF program. That rollout is a transparency win: customers running Azure Linux get a deterministic, automatable signal of whether the Microsoft‑published image ship the vulnerable component and whether a fix is available. However, Microsoft’s product ecosystem is broad:

• Microsoft publishes several Linux kernel artifacts (linux‑azure packages, Azure kernel builds) and also distributes images (marketplace, curated, AKS) that may be built from different trees.
• WSL2 ships a Microsoft‑provided kernel in Windows; the WSL kernel tree is published and configurable, meaning some WSL configurations may not include the nocb code while custom WSL kernels can.
• Microsoft hosts third‑party marketplace images and partner images in Azure; those images may have different patch cadences and are not covered by a Microsoft Azure Linux attestation unless explicitly mapped.
• Some Microsoft services distribute curated container images (for ML, data science runtimes, etc.. Those curated images can include kernel‑dependent components or userland tooling that rely on kernel behavior; the attestation for Azure Linux does not extend automatically to those curated images.

In short: the presence of the upstream nocb bug in a Microsoft product is a question of build provenance and kernel configuration for that product. Microsoft’s VEX attestation for Azure Linux answers that question for Azure Linux; it does not automatically resolve it for the rest of Microsoft’s product surface.

---

Cross‑checks: authoritative references you should use​

When you triage exposure across your estate, cross‑verify vendor attestations with at least two independent technical sources:

• Upstream kernel commit history and linux‑cve‑announce (the kernel CVE team) for commit IDs and the technical patch description.
• Distribution security trackers (Ubuntu, Debian, SUSE, Amazon Linux) to see packaged fix timelines and which packaged kernels were updated.
• Microsoft’s published VEX/CSAF attestations for Azure Linux for product‑level status (the attestation gives actionable automation metadata for Azure Linux customers).

These independent references give you a complete picture: the kernel commits show the fix, distro advisories show packaged fixes and backports, and vendor attestations show product mappings and timelines.

---

Practical examples: what a verification looks like in the field​

• A VM running a Microsoft‑published Azure Linux image:
• Check the image’s kernel version and the image manifest in the Azure portal or via az cli.
• Confirm the kernel package changelog includes the upstream CVE‑2025‑38704 fix commit or that Microsoft’s Azure Linux VEX attestation marks the image as fixed.
• A Windows desktop running WSL2:
• Check the WSL2 kernel shipped with Windows: open a WSL shell and run uname -r and cat /proc/config.gz (if available).
• If you use a custom WSL kernel, confirm whether that kernel’s source includes the upstream fix commits.
• An AKS node pool:
• Inspect the node image version and kernel mapping in the node OS inventory.
• Perform the kernel check on a node and confirm the kernel package contains the fix commit or is on a fixed kernel version.

---

Caveats and unverifiable claims — what to watch for​

• Absence of an attestation for a Microsoft product is not proof of absence of the vulnerable code. The Microsoft VEX/CSAF program is iterative; it maps what has been validated and will be extended when more artifacts are inventoried. Until Microsoft updates the CVE record or you inspect the artifact yourself, the presence/absence remains unverified. Use cautionary language and require confirmation before assuming a Microsoft artifact is unaffected.
• Some third‑party images hosted on Microsoft infrastructure (Marketplace/partner images) are published and maintained by third parties. These may carry long‑tail, unpatched kernels and should be verified independently.
• Kernel crashes can auto‑reboot hosts and erase evidence; ensure persistent logging and crashdump capture is in place so you can validate whether an incident was caused by this defect.

If you cannot confirm the presence/absence of the fix in an artifact and the artifact runs in a high‑risk context (multi‑tenant, shared compute, or internet‑facing workloads), assume potential exposure and prioritize patching or isolation.

---

Clear next steps for Windows and Azure administrators​

• Prioritize inventory: enumerate all Linux kernels in your environment, including those inside VMs, containers, Marketplace images, and WSL2 instances. Use automated asset discovery where possible.
• For any Microsoft‑published Azure Linux images, consume the VEX/CSAF attestation and follow Microsoft’s Azure Linux patch guidance.
• For Marketplace, partner, and third‑party images: inspect image manifests or run the image in a sandbox to verify kernel version and fix presence.
• Enable and validate persistent kernel logging and crashdump collection so you do not lose transient evidence of kernel oops.
• Roll out kernel updates in a staged, tested manner and verify node reboots and service health after the patch is applied.

---

Conclusion​

Microsoft’s MSRC advisory wording for CVE‑2025‑38704 — “Azure Linux includes this open‑source library and is therefore potentially affected” — is a transparent, machine‑readable inventory attestation that benefits Azure Linux customers by reducing uncertainty. It does not constitute a technical guarantee that no other Microsoft product can include the vulnerable rcu/nocb code. The decisive observation is simple and practical: product attestations answer the question “what Microsoft has validated so far?” — they do not answer “what Microsoft cannot possibly ship.”
Operators and administrators must therefore treat the Azure Linux attestation as a starting point: verify every Microsoft image and artifact you run (marketplace images, AKS nodes, WSL2 kernels, curated containers and appliances) by checking kernel versions, configuration, and distribution changelogs for the upstream fix commits. Use upstream kernel commits and distribution advisories as authoritative technical references, and follow Microsoft’s VEX/CSAF updates for product‑level status as the vendor expands its inventory mapping. Applying patched kernels, confirming the upstream commit IDs are present in your packages, and rebuilding immutable images are the only reliable ways to eliminate the exposure. Until you have that confirmation, treat non‑attested Microsoft artifacts as unverified and prioritize hardening, isolation, or patched replacements for high‑risk workloads.

---

---

Source: MSRC Security Update Guide - Microsoft Security Response Center