Azure Linux is the only Microsoft product Microsoft has publicly attested so far to include the upstream component implicated by CVE-2025-38377 — but that attestation is a
product‑scoped inventory statement, not a guarantee that no other Microsoft product or image could contain the same vulnerable code. Treat the Azure Linux VEX/CSAF claim as authoritative for Azure Linux artifacts, and treat the absence of attestations for other Microsoft SKUs as “not yet checked” rather than “not affected.”
Background / Overview
CVE‑2025‑38377 is an upstream Linux kernel fix described as “rose: fix dangling neighbour pointers in rose_rt_device_down”. The bug stems from two loop/index handling errors that can leave freed neighbour pointers in the rose neighbour array, producing a
use‑after‑free when code later assumes those entries are valid. The upstream remedy is straightforward: iterate the neighbour array in reverse with a fixed loop bound so removals don’t skip or leave dangling entries. Public vulnerability trackers, vendor advisories and the kernel stable commits document the change and classify the impact as an availability‑oriented memory corruption concern. Microsoft’s public statement about this CVE follows its recent CSAF/VEX rollout model: Microsoft published a machine‑readable attestation saying
Azure Linux “includes this open‑source library and is therefore potentially affected”, and committed to update the CVE/VEX records if additional Microsoft products are later found to ship the same upstream component. That language is an inventory attestation for a named product family (Azure Linux), not a categorical statement about the rest of Microsoft’s product portfolio.
What the CVE actually is — technical summary
The bug in plain language
- The function rose_rt_device_down manages a per‑device neighbour table used by the ROSE/AX.25 networking logic.
- Two mistakes in that loop allow an entry removal to change the loop bound and then skip entries, leaving freed pointers inside the array.
- Later code that walks the array assumes the first t->count entries are valid and dereferences them — yielding a use‑after‑free and potential kernel OOPS, panic, or other corruption depending on allocator/timing.
The fix
- Iterating the array in reverse with a fixed bound prevents removals from affecting earlier (still-to-be-checked) indices.
- The upstream patch set is small and defensive; it was merged into the stable kernel trees, and distribution vendors have been mapping those commits into their kernel packages.
Impact model and exploitability
- The vulnerability is local in nature: an attacker or misbehaving process with the ability to manipulate ROSE interfaces or trigger device down events on the host must be present.
- Primary impact: availability — kernel oops or panic causing service interruption.
- Escalation to RCE or privilege escalation is theoretical and would require extra conditions; no authoritative public PoC showing RCE was published at disclosure.
Microsoft’s wording: what it means and what it does not mean
Microsoft’s phrasing — that
Azure Linux includes the open‑source library and is therefore potentially affected — serves two operational purposes:
- It is an authoritative, machine‑readable attestation that Microsoft performed inventory work for the Azure Linux family and found the implicated upstream component there. Customers running Azure Linux images should treat that as a prompt to prioritize remediation.
- It is part of a phased rollout of CSAF/VEX attestations that began in October 2025; Microsoft has said it will expand attestations to additional products as inventory checks complete. Absence of an attestation for another product therefore means Microsoft has not yet published a mapping for that product — not that the product was proven free of the code.
Important operational distinction:
- “Known affected” in a vendor VEX feed = the vendor inspected this product and found the component.
- “Not mentioned” = the vendor has not (yet) completed or published inventory for that product; it is not a declaration of safety.
Multiple independent trackers corroborate the CVE description and the upstream commits that implement the fix, and major distributions issued advisories mapping the change to fixed kernel packages. These independent confirmations strengthen the technical picture even while Microsoft’s VEX statement remains product‑scoped.
Is Azure Linux the only Microsoft product that includes the library and is therefore potentially affected?
Short answer:
No — not necessarily.
Long answer:
Azure Linux is the only Microsoft product Microsoft has publicly attested to include the implicated upstream code for this CVE at the time of the advisory. That attestation is authoritative for Azure Linux images, but it does
not rule out the possibility that other Microsoft‑distributed artifacts — WSL2 kernels, Azure Marketplace images, AKS node images, linux‑azure kernels, or Microsoft‑packaged container images — may also include the same upstream code depending on build choices, kernel version, configuration flags and backports. The vendor attestation is phased and product‑scoped; absence of attestations for other SKUs is absence of inventory confirmation, not proof of absence.
Why this distinction matters:
- Kernel code inclusion is an artifact property determined at build time (kernel version, CONFIG flags, modules compiled in/out).
- Microsoft ships multiple distinct Linux artifacts: Azure Linux images (the first to receive VEX), the Microsoft‑built WSL2 kernel, linux‑azure kernels used in some Azure images, and curated Marketplace/partner images — each must be checked individually.
- A single upstream fix committed to kernel/mainline will be propagated to vendors and distributions based on backport policies; different Microsoft artifacts may be built from different kernel trees or configs.
Where you should focus verification — a practical checklist
If you operate in an environment that uses Microsoft artifacts (Azure, WSL, Marketplace images, AKS, etc., follow these prioritized steps to verify exposure and mitigate risk.
- Confirm Azure Linux images first
- Microsoft’s VEX attestation is authoritative for Azure Linux artifacts. If you run Azure Linux (CBL‑Mariner lineage / Azure images), treat them as in‑scope and apply vendor kernel updates.
- Inventory other Microsoft artifacts you run
- Identify any WSL2 kernels, linux‑azure kernels, Marketplace VM images, AKS node images, or Microsoft‑maintained containers you use.
- Extract kernel version (uname -r), and kernel config where available (zcat /proc/config.gz or available config in the image) to see whether the affected rose code and the surrounding kernel version are present.
- Map upstream fixes to your kernel versions
- Use the NVD/OSV / distributor advisories to find the upstream commit hashes and check whether your kernel tree or vendor package includes those commits. If you compile kernels yourself, rebase to the fixed stable commit or apply the upstream patch.
- Check WSL2 kernels and configurations
- WSL2 ships a Microsoft‑built kernel. Public sampling shows many WSL2 builds avoid certain kernel sanitizers/configs, but you must verify the actual kernel binary your environment received. If you use a custom WSL kernel, treat it as a separate artifact requiring inspection.
- Marketplace images & partner appliances
- Marketplace images can include third‑party kernels or vendor‑provided appliances. Validate those images’ kernel versions and vendor fix status directly with the vendor or via published SBOMs/SHA256s when available.
- Use SBOMs, VEX/CSAF and automated tooling
- Consume Microsoft’s CSAF/VEX feed and distributor SBOMs where available. Automate mapping between your image inventory and VEX attestations to accelerate triage. Microsoft committed to publishing programmatic attestations to this effect — use them for Azure Linux and watch for updates to other product attestations.
Detection, triage and mitigation guidance
Detection & hunting
- Inspect kernel logs (dmesg, journalctl -k) for oopses and stack traces referencing ROSE or rose_rt_device_down.
- Collect vmcore / kdump on crashing hosts for offline analysis and to determine whether freed pointers were dereferenced.
- Monitor for repeated kernel WARN/OOPS traces that coincide with device down events for ROSE/AX.25 interfaces.
Immediate mitigations if patching is delayed
- Restrict access to operations that can bring ROSE devices down; limit who can run network device reconfiguration tools or scripts that may trigger the problematic pathway.
- Isolate hosts running multi‑tenant workloads where an untrusted tenant can manipulate ROSE interfaces.
- Schedule maintenance windows to apply fixed kernels and reboot. Given the primary impact is availability, the pragmatic path is kernel patch and controlled reboot.
Remediation
- Apply vendor‑supplied kernel updates that list CVE‑2025‑38377 or include the upstream stable commit hashes.
- If you maintain custom kernels, apply the upstream diff and rebuild with the fixed commit(s) referenced in public trackers.
Operational and supply‑chain implications
- Vendor VEX/CSAF attestations help automate triage by telling you which named products were inventoried and found to include a component. Microsoft’s early VEX rollout starting with Azure Linux is a positive transparency step, but it is inherently phased — other product mappings will appear over time.
- The presence of the same upstream code across multiple Microsoft artifacts is plausible. The same kernel source or driver can be present in several Microsoft‑distributed images depending on build choices and packaging. Thus, defenders must not assume “not listed = safe.”
- For large organizations, the practical approach is to:
- Use SBOMs and image inventories to map all Microsoft artifacts in use.
- Cross‑reference those artifacts against the VEX feed and distribution advisories.
- Prioritize patching for artifacts Microsoft has attested to affected status (Azure Linux first), then expand verification to other Microsoft images or kernels.
Strengths and limitations of Microsoft’s VEX/CSAF approach (critical analysis)
Strengths
- Machine‑readable attestations: VEX/CSAF lets automation quickly decide whether a named product is known affected/not affected/fixed, reducing manual triage load. Microsoft’s initial Azure Linux attestations provide a deterministic signal operators can act on.
- Procedural commitment: Microsoft pledged to update CVE/VEX records when further Microsoft products are identified as carriers, which formalizes a roadmap for expanding inventory coverage.
Limitations and risks
- Phased coverage leaves gaps: Early rollout means many products may not yet be mapped, creating a window where customers might falsely assume absence of risk for products not yet attested.
- Artifact variation: Microsoft ships multiple Linux artifacts (WSL kernels, marketplace images, linux‑azure builds). Each artifact’s build choices determine exposure; VEX attestation for one artifact does not generalize automatically to others.
- Operational complacency risk: Customers who read the short Microsoft phrasing and assume exclusivity could delay necessary inspections of their own Microsoft artifacts, increasing exposure if those artifacts do contain the vulnerable code.
Where to be cautious
- Treat vendor attestations as signals for prioritization, not exhaustive proofs of absence.
- Don’t rely solely on CVE search hits in generic scanners; link a detected kernel version or binary hash back to vendor attestations and upstream commit hashes before declaring a host safe.
Recommended programmatic checks and automation recipes
- Build an inventory pivot that maps:
- All images and VM SKUs in use → extracted kernel version + kernel config → match against upstream commit list for CVE fixes.
- Automate VEX/CSAF consumption:
- Ingest Microsoft’s CSAF/VEX feed and mark any matching product IDs as high priority.
- Reconcile VEX product IDs with your asset inventory (image SHA256s, SKU IDs).
- Use binary provenance where possible:
- Compare kernel image checksums with vendor published checksums or SBOMs to confidently map a binary to a vendor build containing the fix.
- If you run WSL2 or custom kernels:
- Pull the specific kernel binary and config from each Windows host (where feasible) and map against the upstream commit list. WSL2’s public kernel source and config examples are helpful but do not substitute for verifying the actual shipped binary.
Conclusion
Microsoft’s statement that
Azure Linux includes the open‑source library and is therefore potentially affected is accurate and actionable for Azure Linux customers — it’s a product‑level VEX/CSAF attestation designed to help automation and prioritization. However, that same wording is deliberately narrow: it represents the inventory work Microsoft has completed so far and
does not imply Azure Linux is the only Microsoft product that could carry the vulnerable ROSE code. Other Microsoft artifacts that ship Linux kernels (WSL2 kernels, Marketplace images, linux‑azure kernels, AKS node images, or third‑party appliances distributed through Microsoft’s channels) may still include the vulnerable code depending on build/version/configuration, and must be verified independently until Microsoft’s attestations cover them.
Actionable priorities for operators:
- Treat Azure Linux artifacts as known in‑scope and apply the vendor‑supplied kernel updates immediately.
- Inventory other Microsoft artifacts and map their kernel versions/configs to upstream commit hashes for CVE‑2025‑38377.
- Automate CSAF/VEX ingestion and reconcile it with your asset inventory so you can spot when Microsoft publishes additional attestations for other products.
Finally, remain vigilant: vendor attestations are an important new tool in supply‑chain security, but they complement — they do not replace — artifact‑level verification, SBOM‑driven inventories, and routine kernel/package patching.
Source: MSRC
Security Update Guide - Microsoft Security Response Center