A recently assigned Linux-kernel CVE, CVE-2025-38443 — described upstream and by multiple distributors as “nbd: fix uaf in nbd_genl_connect error path” — corrects a use‑after‑free in the NBD (Network Block Device) driver by rearranging device startup so the kernel no longer races between starting the device and creating its backend file. Microsoft’s Security Response Center (MSRC) entry for the CVE calls out Azure Linux as a product that “includes this open‑source library and is therefore potentially affected,” and Microsoft has stated it will expand its machine‑readable CSAF/VEX attestations over time; however, that attestation is product‑scoped and does not, by itself, prove exclusivity across all Microsoft products and artifacts. The practical, defensible takeaway is simple and operational: treat Azure Linux as a confirmed carrier and patch it immediately, but validate other Microsoft‑supplied kernel artifacts in your environment (WSL kernels, linux‑azure images, Marketplace images, AKS node images, curated appliances) rather than assuming they are unaffected.
Background / Overview
The vulnerability CVE‑2025‑38443 was reported and cataloged widely by public vulnerability trackers and by distribution maintainers. It is a kernel‑level use‑after‑free (UAF) rooted in the NBD driver’s setup path: under certain error conditions the driver called nbd_start_device too early, leaving a failure path that would call put on nbd->config while a background recv_work still referenced that same config, producing a classic UAF and kernel oops in recv_work. The upstream remedy is small and surgical: move nbd_start_device until after backend file creation so that object lifetime is no longer races with the recv_work consumers. Why this matters operationally: even though this is a local‑vector kernel robustness bug (not described at disclosure as a trivial remote RCE), small kernel UAFs are dangerous in multi‑tenant or build/test infrastructure because:- A single kernel oops can take down a host and all tenants on it.
- Local attackers, container escape scenarios, misconfigured CI runners, or untrusted build/test fuzzers can reach the vulnerable code path.
- The fix is trivial to backport, but until applied the operational impact can be high in cloud, CI or virtualization contexts.
What Microsoft actually published (and what those words mean)
Microsoft’s MSRC entry for the CVE includes a short, explicit attestation: it reports that Azure Linux includes the implicated upstream open‑source code and is therefore potentially affected; and it explains that Microsoft began publishing machine‑readable CSAF/VEX attestations in October 2025 and will update CVE product mappings if their inventory work later identifies additional Microsoft products that ship the same component. That phrasing is deliberate and procedural: it reflects the scope of Microsoft’s completed inventory work rather than an assertion that no other Microsoft product ever carried the component. Key points to read into Microsoft’s wording:- “Includes … and is therefore potentially affected” = an authoritative attestation that the vendor inspected a product (Azure Linux) and found the upstream file in that product’s artifacts.
- The statement is product‑scoped, not an exclusivity claim. Absence of a VEX/CSAF attestation for other Microsoft products is not proof they lack the code.
- Microsoft’s VEX rollout is phased; they deliberately started with Azure Linux as a first product family to validate tooling and automation before expanding to other SKUs.
Technical summary of CVE‑2025‑38443
What the bug is
- Component: Linux kernel NBD driver (drivers/block/nbd.c).
- Fault class: use‑after‑free in recv_work when nbd_genl_connect takes an error path after starting the device.
- Symptom: KASAN slab‑use‑after‑free or kernel oops during recv_work; logs show “Receive control failed … shutting down sockets” and a stack trace implicating drivers/block/nbd.c.
The upstream fix
- Change: move nbd_start_device to after the backend file creation, so the error path does not release nbd->config while a concurrent recv_work may still reference it.
- Rationale: ensure object lifetimes are correctly serialized and avoid freeing the configuration object while worker threads still use it.
- Upstream status: patch merged into kernel stable trees and then propagated by distribution maintainers. Distributions (Ubuntu, Debian, and others) produce kernel package updates or backports that incorporate the fix.
Is Azure Linux the only Microsoft product that could be affected?
Short answer: No — not necessarily. Azure Linux is the only Microsoft product Microsoft has attested so far to include the implicated upstream NBD kernel code for this CVE, but that attestation reflects the inventory work completed for Azure Linux and does not prove other Microsoft artifacts are free of the vulnerable code. Absence of mention in Microsoft’s published VEX/CSAF feed is absence of attestation, not proof of absence. Why: inclusion of an upstream kernel file is an artifact‑level property that depends on:- The specific upstream kernel commit ranges used to build each kernel binary.
- The kernel configuration options (CONFIG_*) used at compile time — drivers may be built-in, built as modules, or excluded entirely.
- Distribution or vendor backports and build‑time changes.
Because Microsoft builds and ships multiple distinct Linux‑related artifacts (Azure Linux images, linux‑azure kernels for particular VM SKUs, the WSL2 kernel shipped with Windows, curated Marketplace VM images, AKS node images, and partner appliances), each artifact must be checked on its own. A single attestation for Azure Linux does not automatically cover these other artifacts.
How to verify whether other Microsoft artifacts you run are affected
Security teams and sysadmins should treat this as a deterministic verification task. The following actions give a fast, defensible answer for each artifact in your estate.1. Consult Microsoft’s VEX/CSAF feed (authoritative for attested products)
- Check MSRC’s VEX/CSAF output and the CVE product mappings to see whether the artifact you care about is listed as “Known Affected”, “Under Investigation”, “Not Affected” or “Fixed”. Microsoft has committed to updating those attestations when further inventory work is completed.
2. For each image/binary you run, confirm the kernel build contents
- If you run a distribution kernel package (Ubuntu, Debian, etc., consult that vendor’s security advisory and package changelog for the CVE or the upstream commit ID that fixed the issue. Distribution advisories list fixed package versions and branches.
- If you run Microsoft‑supplied artifacts (WSL kernel, linux‑azure, Marketplace images), obtain the image or kernel artifact and:
- Check whether the NBD driver exists: grep for drivers/block/nbd.c or check /lib/modules/$(uname -r)/kernel/drivers/block/nbd*.
- If you rebuild or ship your own kernel, search the kernel git history for the upstream commit or for the fix message (nbd_genl_connect / nbd_start_device reorder).
- If the driver is present as a module, check modinfo nbd and module version. If built‑in, compare kernel build metadata and changelog to the upstream commit.
3. Practical commands and checks
- Check running kernel version and package changelog:
- uname -r
- zcat /proc/config.gz | grep NBD or check /boot/config-$(uname -r)
- dpkg -l | grep linux-image / rpm -q --changelog kernel-*
- Inspect module presence:
- modinfo nbd || lsmod | grep nbd
- Search for upstream commit hashes in packaged source or changelogs:
- zgrep -i 'nbd_genl_connect' /usr/share/doc/*/changelog.Debian.gz
Practical mitigation and remediation guidance
Recommended immediate steps (high‑priority)
- Patch Azure Linux images immediately. Microsoft has attested Azure Linux as a carrier; treat that as definitive for Azure Linux images you run. Apply the vendor kernel update and reboot.
- Patch all Linux kernels in your environment where the NBD driver is present and unpatched (distributions have released fixes; check vendor advisories).
- Reboot hosts after kernel updates to ensure the patched kernel is running.
Interim mitigations when immediate patching isn’t possible
- If NBD is built as a module, consider unloading the module and blacklisting it until you can patch:
- modprobe -r nbd
- echo "blacklist nbd" > /etc/modprobe.d/blacklist-nbd.conf
Note: this disables NBD functionality and may impact any workloads that rely on it.
- Restrict who can create NBD devices and who can access the control interface used to configure NBD backends. Reduce the attack surface by limiting local user capabilities or namespaces able to create/attach NBD transports.
- On multi‑tenant build/test/CICD hosts, implement stronger isolation (dedicated hosts for untrusted CI jobs, strict seccomp, namespaces, and resource quotas) so that untrusted processes cannot exercise kernel setup paths for NBD.
Detection & hunting
- Monitor kernel logs for KASAN reports, WARN_ONs, or oopses mentioning drivers/block/nbd.c or recv_work. Key artifacts include stack traces that show recv_work and nbd functions failing.
- Enable kdump/vmcore collection so that, if a host crashes, you preserve evidence for post‑mortem debugging.
- Use centralized kernel logging and correlate crashes with recent NBD activity or with test jobs/fuzzers that may have exercised the kernel’s NBD setup paths.
Why Microsoft’s VEX approach improves security — and its limits
Microsoft’s decision to publish machine‑readable CSAF and VEX attestations is an unequivocal operational improvement: VEX provides deterministic, automatable answers to whether a vendor‑shipped product contains a specific third‑party component and the vendor’s view of its exploitability. That reduces false positives and helps automation tools decide remedial action more quickly. Microsoft announced this phased roll‑out and began with Azure Linux in October 2025 to validate the approach before scaling to many more SKUs. The limitation is procedural, not technical: VEX attestation completeness lags the vendor’s inventory cadence. A single attestation for Azure Linux does not automatically cover other Microsoft products — each product or artifact must be inventoried and attested. The correct operational approach therefore combines reliance on the vendor’s attestations where available with per‑artifact verification and standard patching practices where they are not.Risk analysis and recommendations for enterprise teams
Strengths in Microsoft’s approach
- Transparency: Publishing VEX/CSAF makes Microsoft’s inventory claims machine‑readable and actionable, which reduces time to remediate for customers using automated vulnerability management.
- Priority focus: Starting with Azure Linux allowed Microsoft to rapidly publish accurate attestations for a high‑value product family while validating processes.
Residual risks and operational caveats
- Artifact fragmentation: Microsoft and other large vendors ship many kernel artifacts and images. Attestations for a single product do not guarantee the absence of the vulnerable code elsewhere.
- Time‑to‑attest: Inventory and attestation processes take time; customers must not assume “not listed” equals “not affected.”
- Local‑vector kernel flaws remain dangerous in multi‑tenant and CI environments; attackers can often escalate a local reliability bug into a larger operational impact.
Action checklist for defenders (priority order)
- Apply vendor kernel updates and reboot Azure Linux hosts now.
- Inventory all Microsoft‑supplied Linux artifacts you run (WSL kernels, linux‑azure, Marketplace images, AKS node images). Verify presence/absence of NBD and patch accordingly.
- If uncertain, assume the artifact is unverified and treat it as potentially affected while you confirm.
- Harden multi‑tenant/test/CI hosts: isolate untrusted runs, restrict access to device/control interfaces, and enforce least privilege.
- Centralize kernel‑level telemetry and enable kdump so crashes are preserved for analysis.
Final assessment and cautionary notes
Azure Linux is the only Microsoft product Microsoft has publicly attested to include the vulnerable NBD code for CVE‑2025‑38443 at the time of MSRC’s advisory; that attestation is authoritative for Azure Linux and should drive immediate remediation for customers who run those images. However, technical realities of kernel builds and Microsoft’s phased VEX rollout mean other Microsoft artifacts could still contain the upstream code — this is an artifact‑by‑artifact fact, not a product‑level universal truth. Until Microsoft’s VEX feed expands or you independently validate your artifacts, do not assume any Microsoft‑shipped kernel is free of the vulnerable code. Unverifiable claims flagged: whether any specific Microsoft product beyond Azure Linux currently includes the vulnerable NBD code cannot be confirmed without either (a) Microsoft publishing an explicit attestations for that product in the VEX/CSAF feed, or (b) an independent inspection of the particular artifact’s kernel build/configuration or shipped module set. Any statement claiming “no other Microsoft product is affected” is therefore unverified until Microsoft’s inventory is expanded or artifacts are examined.CVE‑2025‑38443 is straightforward to fix at scale: update kernels and reboot. The harder, but essential, work for large organizations is artifact inventory — proving which images and kernels are present in production, CI and developer systems, and ensuring each has received the backport or update. Microsoft’s VEX/CSAF rollout materially helps that work by making vendor attestations machine‑readable, but defensive teams must combine VEX with per‑artifact verification and rigorous patch management where VEX attestations are not yet published.
Source: MSRC Security Update Guide - Microsoft Security Response Center
