CVE-2025-38184: Azure Linux Carrier of TIPC Bug — Verify Artifacts

Microsoft’s advisory that Azure Linux is the product Microsoft has identified as shipping the affected library in CVE-2025-38184 is accurate — but it is not a technical guarantee that no other Microsoft product could include the same vulnerable code. The VEX/CSAF attestation Microsoft published confirms Azure Linux artifacts were inspected and mapped to the upstream kernel component (the TIPC codepath fixed for the null-pointer dereference), and Microsoft has promised to update its CVE records if additional products are found to carry the same upstream code. In short: Azure Linux is a confirmed carrier; absence of other Microsoft product names in the attestation is not proof those products are clean — artifact‑level inspection remains the reliable way to determine exposure.

---

Background / Overview​

CVE-2025-38184 is an upstream Linux kernel vulnerability fixed in the TIPC (Transparent Inter-Process Communication) networking code. The bug is a classic null pointer dereference that can occur when code attempts to acquire the remote IP address of an Ethernet bearer under particular conditions. The defect was reproduced using KASAN traces on recent kernel trees and fixed upstream with a targeted check to avoid dereferencing a possibly NULL bearer entry.
Microsoft’s Security Response Center (MSRC) has published a product‑level statement and machine‑readable VEX/CSAF attestation indicating that Azure Linux (the Microsoft-distributed Linux distribution formerly known as CBL-Mariner) includes the implicated open-source code and is therefore potentially affected. The MSRC text goes on to explain Microsoft’s CSAF/VEX rollout (started October 2025) and says the company will update the CVE if additional Microsoft products are discovered to include the same upstream library.
Multiple independent vulnerability trackers (NVD, distribution security trackers including Debian, Ubuntu and SUSE, and vendor advisories) confirm the technical scope of the upstream fix and show how downstream distributions mapped the remediation to their kernels.

---

What the vulnerability actually is​

The technical summary​

• The bug lives in the TIPC UDP/ethernet media path in the Linux kernel.
• Under a specific sequence (create a tun interface, enable an L2 bearer, and invoke a TIPC netlink query for remote IP with the media name set to the tun interface), a code path can attempt to dereference a bearer pointer that has become NULL or been changed by another thread, causing a kernel oops (KASAN: null-ptr-deref).
• The problematic routine is in the TIPC UDP media code (the net/tipc udp_media handling), and the upstream fix adds checks to ensure the media_id / bearer pointer is valid before accessing it.

Practical impact profile​

• Primary impact: availability — kernel oops, general protection fault, or panic on affected kernels.
• Attack vector: local — the trigger requires local or guest-level ability to craft the sequence of netlink operations or manipulate network namespace interactions; in cloud settings with multi-tenant workloads the attack surface can be higher.
• Privilege escalation or remote code execution: not the immediate outcome of this bug as fixed upstream; however kernel panics on shared infrastructure are dangerous and can aid larger attack scenarios. The immediate operational risk is stability and availability rather than a straightforward remote RCE.

---

What Microsoft published and what it means​

Microsoft’s advisory language for this CVE is focused and procedural. The company:

• Published a machine‑readable VEX/CSAF attestation stating that Azure Linux includes the upstream open-source component implicated by CVE-2025-38184 and is therefore “potentially affected.”
• Reiterated Microsoft’s transparency commitment and its recent rollout of CSAF/VEX for Azure Linux (announced October 2025).
• Promised to update the CVE/VEX records if additional Microsoft products are later identified to include the same upstream component.

Key reading points:

• The VEX/CSAF attestation is an authoritative statement that Azure Linux has been inspected and the component was found there. Treat that attestation as definitive for Azure Linux artifacts.
• The attestation is product‑scoped and phased. Microsoft’s program intentionally starts with Azure Linux and will expand. The company’s phrasing — that it will update records if additional products are identified — is standard for a staged inventory rollout.
• Importantly, lack of an attestation for other products is not proof of absence. It simply means Microsoft has not yet published a verified mapping for those products in the VEX feed.

---

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

Short answer: No — not necessarily.
Long answer: Microsoft has publicly attested that Azure Linux includes the library. That is a positive and useful signal: Azure Linux images should be treated as potentially affected until patched. However, Microsoft distributes many Linux kernel artifacts across different products and channels (WSL2 kernel images, linux-azure kernel builds for Azure VMs, specialized Marketplace images, AKS node images, and others). Whether each of those artifacts contains the vulnerable TIPC code depends on:

• The kernel version shipped in that artifact.
• The upstream commit range and whether the fix was merged or backported into the specific vendor kernel branch.
• Build-time kernel configuration flags (for example CONFIG_TIPC can be built-in, built as a module, or omitted entirely).
• Any vendor-specific backports or removals.

Because these are artifact-level properties, Microsoft’s single-product attestation does not, by itself, prove exclusivity. Operators must verify the actual kernels in use.

---

Why this matters: builds, configs and artifact variance​

Large vendors ship many kernel artifacts. Two kernels from the same vendor can differ in crucial ways:

• Kernel version (e.g., 5.15 vs 6.1 vs 6.16).
• Backported fixes: vendors often backport security fixes into older stable branches rather than upgrading the kernel version number.
• CONFIG_* flags: kernel subsystems can be enabled, disabled, or built as modules, changing whether a piece of source code is present in a shipped artifact.
• Module packaging: even if a subsystem is available as a module, it may not be installed in a given image.

Therefore, only artifact inspection — checking the running kernel, module set, or the image’s /boot/config-<version> and changelog — yields a definitive answer about exposure for that particular host or image.

---

How to verify if your Microsoft-supplied instance is affected​

You should treat the vendor VEX attestation as a strong signal but validate per artifact when possible. On any Linux host (VM, container host, WSL instance), perform the following checks:

• Confirm the running kernel version:
• uname -r
• Check whether TIPC is present in the kernel config:
• zgrep CONFIG_TIPC /proc/config.gz
• or grep CONFIG_TIPC /boot/config-$(uname -r)
• Possible values:
• CONFIG_TIPC=y (built-in)
• CONFIG_TIPC=m (module)
• CONFIG_TIPC is absent or =n (not built)
• If TIPC is a module, check whether it’s installed/loaded:
• lsmod | grep tipc
• modinfo tipc
• Inspect kernel package changelog or vendor advisory mapping:
• On Debian/Ubuntu: apt changelog linux-image-$(uname -r)
• On RPM-based systems: rpm -q --changelog kernel | grep -i CVE-2025-38184
• Compare the package changelog to upstream commit IDs referenced in kernel security advisories.
• For WSL2:
• If you use the default Microsoft‑supplied kernel, ensure Windows Update has been applied or check the WSL kernel version inside your distribution with uname -r.
• If you use a custom WSL kernel, inspect its config and rebuild with the fixed upstream source if necessary.
• For offline images and Marketplace/AKS images:
• Mount the image and inspect /boot/config-<version> or the kernel package metadata to determine if the fix is present.

If a host lacks kernel config or package metadata, treat the artifact as unknown and assume possible exposure until confirmed otherwise.

---

Patching and mitigation guidance​

• For Azure Linux customers:
• Follow Microsoft’s Azure Linux kernel updates and apply vendor-supplied kernel packages. Reboot into the patched kernel as required.
• Use your normal patch management pipeline; the VEX attestation identifies the specific artifacts Microsoft inspected.
• For WSL2 users:
• Ensure Windows Update is applied if you rely on Microsoft’s supplied WSL kernel.
• If you run a custom WSL kernel, rebuild or switch to the supplied kernel until the custom build has the fix applied.
• For Azure Marketplace images, AKS node images, and other Microsoft-distributed artifacts:
• Treat images individually. Replace with patched images where the vendor has released updates, or extract and inspect the kernel config and package changelog.
• Short-term mitigations when immediate patching is impractical:
• Restrict access to interfaces that could be used to exercise TIPC (cluster networks, admin endpoints).
• Blacklist the tipc module if you do not require the subsystem: add a modprobe blacklist entry or rebuild kernels without CONFIG_TIPC.
• Isolate and quarantine unknown or high-risk VMs.
• Increase kernel log collection (journalctl -k, dmesg) and enable kdump/crash capture to preserve traces if an oops or panic occurs.

---

Risk analysis: who should worry most?​

• Highest priority: multi-tenant hosts and systems that run untrusted guest workloads where local or guest-level operations could cause the trigger sequence. In cloud contexts, the potential for tenant-adjacent attacks increases operational risk.
• Medium priority: servers that host untrusted workloads or are network-adjacent to untrusted tenants, where local operations might be possible.
• Lower priority: single-tenant desktops or VMs with restricted local access and no TIPC usage — still verify though, because a kernel oops on a critical server is disruptive.

The fix reduces the chance of stability-impacting dereferences; however, the possibility of local abuse of kernel races means operators should prioritize patching in environments where multi-tenancy or untrusted workloads are present.

---

Strengths and limitations of Microsoft’s CSAF/VEX approach​

Strengths​

• Machine-readable attestations (VEX) make it easier to automate mapping of CVEs to vendor products and specific artifacts, reducing noise for vulnerability management systems.
• Microsoft’s decision to start with Azure Linux for a phased rollout is pragmatic: focusing on one product family first reduces errors and ensures high-quality attestations.
• VEX clarifies which product artifacts were inspected and what their status is (Not Affected, Under Investigation, Known Affected, Fixed), improving decision-making for customers and security tooling.

Limitations and risks​

• Phased coverage creates gaps. A single product attestation does not imply exhaustive scanning across all Microsoft artifacts. Enterprises must not interpret absence of an attestation as evidence that an artifact is free from a component.
• Artifact variance (kernel version, backports, CONFIG flags) means that product-level attestation cannot replace artifact-level inspection for definitive answers.
• Operational complexity. Organizations must adapt their vulnerability management to ingest VEX while still performing runtime checks and image inspections to validate exposure across heterogeneous fleets.

Microsoft’s public messaging explicitly acknowledges these constraints: they will update VEX entries as more products are analyzed. That transparency is beneficial, but it places responsibility on operators to combine vendor attestations with their own artifact-level checks.

---

Practical recommendations for enterprises​

• Ingest Microsoft’s CSAF/VEX feeds into your VM and SBOM tooling to automate initial triage.
• Treat VEX attestations as high-quality signals, not as definitive global proof. Use them to prioritize workstreams.
• Perform artifact-level verification for all Microsoft-supplied kernels in your estate:
• Uname, kernel config checks, module checks, package changelog inspection.
• Prioritize patching for hosts that are multi-tenant, expose untrusted workloads, or are critical to service availability.
• If you cannot patch immediately, apply short-term mitigations (restrict TIPC exposure, blacklist module, isolate VMs).
• Maintain centralized kernel logging and enable crash capture to preserve diagnostic data if incidents occur.
• Work with vendors (Microsoft, image publishers, ISVs) to request attestations for specific artifacts that matter to your environment if they’re not yet in the VEX set.

---

Verifying Microsoft’s wording — why the wording was intentional​

Microsoft’s answer to the question “Is Azure Linux the only Microsoft product that includes this open-source library?” is careful and precise:

• It confirms Azure Linux has been inspected and found to include the component.
• It highlights Microsoft’s commitment to transparency via CSAF/VEX and its October 2025 VEX rollout for Azure Linux.
• It explicitly says: If impact to additional products is identified, we will update the CVE to reflect this.

That phrasing is deliberate: it prevents customers from assuming a negative — absence of an attestation doesn’t imply absence of risk. For security teams, a conservative stance is safer: assume unknown artifacts may be carriers until you confirm otherwise.

---

Conclusion​

Microsoft’s public statement that Azure Linux “includes the open-source library and is therefore potentially affected” is correct and useful. The company’s VEX attestation identifies an authoritative, machine‑readable mapping for Azure Linux and commits to expanding attestations as inventory work continues. However, Microsoft’s attestation does not serve as a global exclusivity guarantee. Other Microsoft artifacts (WSL2 kernels, linux-azure builds, Marketplace images, AKS node images, or specialized images) may or may not include the same upstream TIPC code depending on kernel version, backports, and compile-time configuration.
Operators must combine vendor-provided VEX signals with artifact-level verification — checking kernel versions, kernel config, modules, and package changelogs — to determine exposure across their environments. Prioritize patching and image replacement in multi-tenant and high-exposure contexts, ingest VEX/CSAF data into automation pipelines to reduce noise, and if needed apply short-term mitigations (module blacklisting, image isolation) while remediation is scheduled.
Treat Microsoft’s Azure Linux attestation as an authoritative hit for that product family — and treat the absence of attestations for other Microsoft products as a prompt to verify, not a clearance.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center