Microsoft’s brief MSRC advisory that “Azure Linux includes this open‑source library and is therefore potentially affected” is accurate for the Azure Linux product family, but it is a
product‑scoped attestation — not a categorical claim that no other Microsoft product can include the same vulnerable code.
Background / Overview
CVE‑2025‑21768 is a Linux kernel networking defect described in upstream changelogs and vendor advisories as “net: ipv6: fix dst ref loops in rpl, seg6 and ioam6 lwtunnels.” In short, certain IPv6 lightweight tunnel (lwtunnel) code paths can create a self‑referencing dst cache entry when a packet’s destination is unchanged after a transformation; that creates a reference cycle that prevents proper freeing of the lwtunnel state and causes per‑CPU memory to leak. Public trackers record the vulnerability and list the upstream stable commits that fix the issue. This article explains what Microsoft’s statement about Azure Linux means in practical terms, why the nuance matters for enterprise defenders, which Microsoft images or kernel artifacts could also carry the vulnerable code, and how operations teams should verify and remediate exposed assets.
What Microsoft actually said — precise reading
Microsoft’s Security Response Center published a short advisory noting that
Azure Linux includes the implicated open‑source library and is therefore potentially affected, and explained that Microsoft began publishing machine‑readable CSAF/VEX attestations in October 2025 and will update the CVE record if more products are identified as carriers. That MSRC blog post confirms the start of the VEX rollout for Azure Linux and explains the phased, product‑by‑product approach Microsoft is taking with machine‑readable attestations.
- Key point: Microsoft’s phrasing is an inventory attestation for Azure Linux — it is authoritative for that product family only.
- Not claimed: Microsoft did not say other Microsoft products are guaranteed free of the upstream component; absence of a VEX attestation for another product is not proof the product lacks the component.
Why the nuance matters: attested vs exclusive
Large vendors that ship many images, kernels, and appliance artifacts usually publish VEX/CSAF attestations in phases. An attestation signals the vendor has completed the inventory and binary mapping for the named product family and is declaring the product’s status for that CVE (Known Affected / Not Affected / Under Investigation / Fixed). It does not imply the vendor has scanned every image, kernel build, marketplace appliance, or embedded artifact the company has ever published. Microsoft made this explicit in its VEX rollout messaging. Technical reasons the same upstream kernel code
may or may not appear in other Microsoft artifacts:
- Kernel features and drivers are included or omitted at build time by CONFIG_* flags. Two kernels built from the same upstream tree can have different surface area.
- A feature can be built into the kernel binary or compiled as a module. A module present on disk may not be loaded at runtime, or conversely a built‑in code path will always be present.
- Microsoft ships multiple Linux kernel artifacts: Azure Linux images (CBL‑Mariner lineage), the linux‑azure kernel used in some VM SKUs, WSL2 kernel builds, curated marketplace images, and partner/third‑party marketplace appliances. Each is a separate artifact that needs its own inventory mapping.
Therefore, the correct operational interpretation is: Microsoft has
confirmed Azure Linux includes the library; other Microsoft products may still include the same code until Microsoft attests them or you verify locally.
The technical nature of CVE‑2025‑21768 (concise)
- Vulnerable area: Linux kernel IPv6 lwtunnel code paths (rpl, seg6, ioam6).
- Fault: certain lwtunnels maintain a dst cache for the post‑transformation dst; if the packet destination doesn’t change, the lwtunnel can end up referencing itself in that cache, producing a reference cycle that prevents freeing, leading to memory leaks (per‑CPU memory retention).
- Impact profile: availability/resource exhaustion (memory leaks). Most public trackers and distribution advisories classify the issue as an availability‑oriented kernel defect with local/guest‑adjacent attack vectors rather than a simple remote RCE.
- Fix: upstream kernel commits change how the dst cache and lwtunnel lifecycle are handled so the cycle cannot occur; fixed commits are merged into stable trees. Distribution vendors map these commits to package updates.
Is Azure Linux the only Microsoft product that includes the open‑source library and is therefore potentially affected?
Short answer:
No — not necessarily. Azure Linux is the only Microsoft product Microsoft has publicly attested to include the component for this CVE at the time of the advisory, but other Microsoft artifacts could also include the same upstream kernel code depending on how they were built and packaged. Treat Microsoft’s Azure Linux VEX assertion as a definitive
yes for Azure Linux and
not a universal exclusion for all Microsoft products. Why this is true in practice:
- Microsoft’s VEX/CSAF rollout was intentionally phased and started with Azure Linux; that does not mean other product lines have been scanned yet. Microsoft committed to update VEX entries if further products are found to ship the implicated component.
- Other Microsoft images that can contain a kernel build or modules — for example, WSL2 custom kernels, linux‑azure kernels for specific VM SKUs, Marketplace images, or partner appliances — are discrete artifacts with independent build choices and may include or omit the lwtunnel code paths depending on the kernel config used.
Real‑world examples of Microsoft artifacts to check
- Azure Linux (CBL‑Mariner / Azure Linux distribution) — Microsoft has attested this family. Treat it as confirmed in scope until the VEX status changes to Fixed.
- linux‑azure kernel packages used on some Azure VM families — separate kernel builds that should be verified independently.
- WSL2 kernel image(s) — the kernel shipped with WSL or any customized WSL kernel must be checked.
- Azure Marketplace images and third‑party appliances — publishers may include kernels or modules not covered by Microsoft’s Azure Linux attestation.
- Managed service images and container base images published by Microsoft — if they embed or ship a kernel or kernel modules (less common for containers, but possible for appliance images), they must be inventoried.
How to verify whether a given Microsoft artifact is affected
Verification must happen at the artifact level. Microsoft’s VEX is authoritative for products it enumerates, but local checks confirm whether your deployed instances actually carry the vulnerable code.
On a running Linux host (VM, WSL, container host) use these quick checks:
- Check kernel version and uname:
- uname -a or uname -r — get the running kernel version and map it to vendor advisories.
- Check installed kernel package changelogs:
- On Debian/Ubuntu: apt changelog linux-image-$(uname -r) | grep -i 21768
- On RPM systems: rpm -q --changelog kernel | grep -i 21768
Matching upstream commit IDs in the changelog indicates the fix is present.
- Inspect kernel config for relevant features:
- zgrep CONFIG_IPV6 /proc/config.gz or check /boot/config-$(uname -r)
- Look for lwtunnel, seg6, rpl, ioam6, and related CONFIG_* entries to understand whether those subsystems exist in the build.
- Module/binary presence:
- lsmod | grep seg6
- modinfo seg6 or modinfo lwtunnel (if compiled modular)
- If the code is built in, it won’t appear as a module; rely on kernel config or compile‑time metadata.
- For image artifacts (offline or Marketplace images):
- Extract the kernel image or inspect the image’s /boot/config-* and package metadata, or consult the supplier’s SBOM or CSAF/VEX if available.
If you rely on Microsoft’s VEX/CSAF outputs, automate ingestion where possible — Microsoft publishes machine‑readable attestations for Azure Linux (and will expand coverage) to make this mapping automatable. However, do not use a VEX absence as proof of absence; always run artifact checks for critical infrastructure.
Operational risk and prioritization
- Primary risk: gradual memory leaks and availability degradation on hosts handling affected IPv6 lwtunnel flows. On multi‑tenant hosts or appliances that handle large numbers of tunnels, leak accumulation could lead to resource exhaustion and instability.
- Exploitability: current public information frames this as a kernel reliability/resource leak issue with local or tenant‑adjacent vectors rather than a simple unauthenticated remote RCE. That makes it high priority for shared and cloud‑multi‑tenant infrastructure.
- High‑priority assets:
- Multi‑tenant VM hosts, NFV platforms, virtual routers, or any host running many IPv6 tunnel flows.
- WSL/VM images used for developer toolchains in environments where those images are also used as part of CI or build pipelines and could be exposed to crafted traffic.
- Marketplace appliances that embed kernels and are exposed to untrusted networks.
Recommended prioritization approach:
- 1. Inventory all Microsoft‑supplied Linux artifacts in your estate (Azure Marketplace images, WSL kernels, managed images).
- 2. Cross‑reference with Microsoft’s VEX/CSAF outputs for Azure Linux and watch for expanded attestations.
- 3. Where the artifact contains the relevant kernel subsystems, plan kernel upgrades or vendor package updates that include upstream stable fixes.
- 4. For unpatchable appliances, implement mitigations where possible (restrict management/tenant‑level access to control planes and limit untrusted tunnel installation).
Practical remediation and mitigations
- Apply vendor or distribution kernel updates that advertise the upstream stable commit(s) for CVE‑2025‑21768.
- Reboot policies: kernel fixes require reboots; schedule maintenance windows for affected hosts and update orchestration to handle rolling reboots safely.
- Short‑term mitigations for hosts that cannot be updated immediately:
- Reduce or disable the use of the affected lwtunnel modes if operationally feasible.
- Isolate hosts that accept untrusted tunnel configuration or tenant‑installed tunnels; tighten management plane controls.
- Enhance monitoring for kernel logs referencing lwtunnel, seg6, or ioam6 warnings and for unexplained memory growth in per‑CPU pools.
Strengths and risks of Microsoft’s VEX/CSAF approach
Strengths:
- Machine‑readability: VEX/CSAF makes vendor attestations automatable and reduces ambiguity for defenders acting at scale. Microsoft’s public VEX rollout for Azure Linux is a clear practical improvement for defenders who run Azure Linux images.
- Transparency: Microsoft’s blog and VEX attestations give direct, product‑scoped answers for customers rather than requiring guesswork from package names or generic CVE records.
Risks / gaps:
- Partial coverage during phased rollout: Publishing VEX for one product family leaves other artifacts unanalyzed until Microsoft expands the mapping; this creates a temporary visibility gap for customers running diverse Microsoft images.
- Automation complacency: Organizations that treat a vendor’s VEX absence as proof of absence for their entire estate risk missing exposures. Artifact‑level verification remains necessary.
- SBOM and image variance: Marketplace and third‑party images hosted by Microsoft are not the same as Microsoft‑curated Azure Linux artifacts; their exposure depends on the image publisher’s build choices and may or may not be covered by Microsoft’s attestations.
Recommended next steps for defenders (practical checklist)
- Inventory Microsoft images and kernel artifacts in your estate (Azure, Marketplace, WSL, managed images).
- Ingest Microsoft’s CSAF/VEX data for Azure Linux and subscribe to MSRC updates; expect additional attestations as Microsoft expands coverage.
- Run artifact‑level checks (uname, /boot/config, modinfo, package changelogs) for hosts you operate — do not rely solely on VEX absence as evidence of safety.
- Prioritize patching and rolling reboots for hosts that include the affected kernel code paths (seg6, rpl, ioam6, lwtunnel).
- Lock down management/control planes for any software that installs tunnels or manipulates network namespaces to reduce the local‑attacker surface.
- Monitor kernel logs for lwtunnel or seg6 warnings and for unusual per‑CPU memory growth; preserve and escalate traces that look like upstream warnings tied to dst cache lifecycle anomalies.
Conclusion
Microsoft’s MSRC statement that “Azure Linux includes this open‑source library and is therefore potentially affected” is a precise, product‑level attestation that benefits Azure Linux customers by providing an authoritative, machine‑readable signal. However, it is not an exclusive declaration that other Microsoft products cannot include the same upstream library. Other Microsoft artifacts — WSL kernels, linux‑azure kernels, Marketplace images, or partner appliances — can carry the vulnerable kernel code depending on how they were built, and each artifact requires independent verification. Operationally, treat the Azure Linux VEX attestation as a high‑confidence yes for Azure Linux, but continue artifact‑level discovery and patching across your entire estate to ensure there are no unexpected carriers of the vulnerable code. Prioritize vendor package updates and reboots where the kernel subsystems are present, automate VEX/CSAF ingestion where possible, and maintain defensive controls around tunnel configuration and management planes while remediation proceeds.
Source: MSRC
Security Update Guide - Microsoft Security Response Center