CVE-2025-38109 Linux mlx5 UAF: Shutdown Fix and Azure Linux Attestation

The Linux kernel patch that fixed CVE-2025-38109 addresses a use‑after‑free during shutdown in the mlx5 driver’s ECVF (embedded chip virtual function) vport teardown — and Microsoft’s public advisory and machine‑readable VEX/CSAF attestation currently name Azure Linux as the Microsoft product that contains the implicated open‑source component. That attestation is authoritative for Azure Linux, but it is not a technical guarantee that no other Microsoft product could carry the same mlx5 code; operators should treat Azure Linux as a confirmed carrier while performing artifact‑level verification for other Microsoft‑distributed kernels and images.

Background / Overview​

CVE‑2025‑38109 is tracked in upstream Linux and by NVD as “net/mlx5: Fix ECVF vports unload on shutdown flow.” The underlying fault is a shutdown‑time UAF (use‑after‑free) observable when a virtual function exists on the embedded BlueField chip (ECVF); the vport ACL ingress table can remain improperly destroyed, leading to a refcount underflow and kernel oops. The call traces in vendor advisories show the failure bubbling through mlx5_core teardown paths such as mlx5_destroy_flow_table and mlx5_eswitch_unload_ec_vf_vports.
Major distro trackers (Ubuntu, Oracle/ULN, Red Hat listings, etc.) published advisories and fixed kernel packages after upstream commits went in; Ubuntu’s advisory classifies the issue as a high‑severity robustness/availability problem for affected kernels and lists the applicable kernel package mappings.
Microsoft’s public statement for this CVE follows a pattern the company has been using for Linux component CVEs: it published a short product‑level attestation that “Azure Linux includes this open‑source library and is therefore potentially affected,” and the company has rolled out machine‑readable CSAF/VEX attestations beginning with Azure Linux to make these inventory claims automatable. Microsoft also states it will update the CVE/VEX mapping if additional Microsoft products are found to ship the same upstream component.

---

What the vulnerability actually is (technical summary)​

• Component: net/mlx5 (Mellanox/NVIDIA ConnectX / BlueField RDMA/ESwitch driver).
• Fault class: shutdown flow use‑after‑free due to incomplete teardown of the vport ACL ingress table when an ECVF virtual function exists.
• Observable symptom: refcount_t underflow warnings in lib/refcount.c and kernel oops traces during device unload or system shutdown. Example traces show stack frames in mlx5_destroy_flow_table, esw_acl_ingress_table_destroy, and mlx5_eswitch_unload_ec_vf_vports.
• Impact: Primary impact is availability — kernel warnings, oops or panics; not an immediate remote RCE. CVSS and vendor feeds place the vulnerability in the medium–high availability risk range depending on scoring and environment.

Why this happens: the driver’s ECVF vport disable/unload logic conditionally skips certain cleanup steps if it assumes ecpf_vport_exists or other capability checks gate ECVF behavior. Upstream fixes ensure that ECVF vports are unconditionally cleaned up in the shutdown path and restore correct reference counting so teardown does not leave stale pointers that later get freed while another path still holds references. The fix is surgical and focused on the vport teardown call sequences.

---

Microsoft’s attestation: what it says — and what it does not say​

Microsoft’s public CVE entry for Linux kernel component CVEs uses short, product‑scoped language mapping the upstream component to a Microsoft product. For CVE‑2025‑38109 Microsoft’s inventory attestation identifies Azure Linux (Microsoft’s maintained Linux distribution formerly known as CBL‑Mariner) as including the implicated mlx5 component and therefore “potentially affected.” That statement is authoritative for Azure Linux customers: it means Microsoft inspected its Azure Linux build artifacts and found the offending upstream code.
Crucially, that Microsoft wording is a product‑scoped inventory attestation, not an exclusivity certificate. Many community analyses and vendor‑neutral explainers make the same point: naming Azure Linux simply says Microsoft completed the inventory for that product and found the vulnerable component there; it does not technically prove that other Microsoft artifacts could not include the same upstream code. Microsoft has pledged to expand its CSAF/VEX coverage and update mappings if it discovers additional Microsoft products that ship the same component.

---

Short operational answer to the user’s question​

• For Microsoft’s public attestation: Yes, Azure Linux is the only Microsoft product that Microsoft currently declares as containing the vulnerable mlx5 component for CVE‑2025‑38109. That is Microsoft’s authoritative, published inventory result at the time of the advisory.
• For technical possibility and risk: No, Azure Linux is not necessarily the only Microsoft product that could include the same code. Other Microsoft‑distributed Linux kernel artifacts (for example, the WSL2 kernel builds, linux‑azure kernels used in some VM SKUs, Marketplace/partner VM images, AKS node images or other curated platform images) could include the mlx5 driver depending on kernel config, version and packaging choices — and should be treated as unverified until attested or inspected.

Put plainly: Microsoft’s attestation reduces ambiguity for Azure Linux customers and gives them a clear remediation priority, but absence of a VEX/CSAF attestation for other Microsoft artifacts is not proof those artifacts are safe. Operators must verify other Microsoft‑provided kernels and images themselves.

---

How to verify exposure in your environment (practical checklist)​

The practical exposure to CVE‑2025‑38109 depends on whether a host actually includes and loads the mlx5 driver and whether ECVF/SR‑IOV features are enabled or used. Use the checklist below to move from “unknown” to “known” quickly.

• Inventory kernels and images:
• Identify Microsoft‑supplied Linux artifacts you run: Azure Linux images, curated VM images in the Azure Marketplace, AKS node images, Windows WSL2 kernels installed on client systems, and any other Microsoft‑distributed kernels.
• Check MSRC’s CSAF/VEX feed for Azure Linux and watch for updates to other product mappings (Microsoft has started with Azure Linux and will expand over time).
• Verify module presence at runtime:
• On each host, run: lsmod | grep mlx5_core (or equivalent) to see if the mlx5 driver is loaded.
• If compiled into the kernel, check dmesg / journal for mlx5_core messages or the presence of mlx5-related devices.
• Confirm kernel package and vendor advisory:
• Map your kernel version / package to vendor security advisories (Ubuntu, Red Hat, Oracle Linux, SUSE, Amazon Linux, etc.). Vendors publish package names and fixed versions for CVE‑2025‑38109. Ubuntu’s advisory page and NVD list fixed kernels.
• Check dmesg for the specific symptom:
• Search kernel logs for “refcount_t: underflow”, “mlx5_core”, or the call trace patterns shown in vendor advisories. Those lines are canonical indicators the vulnerable code path executed.
• Inspect the kernel configuration and build artifacts:
• If you manage custom or Microsoft‑provided kernels, examine the kernel config used to build the image (CONFIG_MLX5_CORE, CONFIG_MLX5_ESWITCH, SR‑IOV options) and the kernel source/commit range to see whether the upstream fixes are present.
• Use SBOM / CSAF / VEX where available:
• For images that expose SBOMs or machine‑readable VEX attestations, ingest those into your vulnerability‑management pipeline to automate “known affected / fixed / not affected” decisions. Microsoft’s VEX rollout is intended to power this automation for Azure Linux first.

---

Mitigation and remediation guidance​

• Primary remediation: apply vendor‑supplied kernel updates that include the upstream mlx5 fix. All mainstream distributions that shipped kernels affected by CVE‑2025‑38109 have released packages or backports. Prioritize hosts that run mlx5 hardware (Mellanox/NVIDIA ConnectX, BlueField) and those that use SR‑IOV / ECVF features.
• If immediate patching is impossible:
• Isolate affected systems from untrusted workloads.
• If your workload uses SR‑IOV or virtual functions on BlueField/ConnectX hardware, consider disabling ECVF vports or SR‑IOV features if that configuration is removable and acceptable operationally — but treat these as workarounds only and confirm they are supported in your environment before making changes.
• Monitor kernel logs for refcount underflow traces or mlx5 teardown warnings and schedule maintenance windows to apply fixes.
• Don’t rely on “no published attestation” alone:
• Even if MSRC’s VEX feed lists only Azure Linux today, apply the verification checklist above for other Microsoft artifacts you run; a lack of Microsoft attestation does not automatically mean your instance is safe.

---

Why Microsoft singled out Azure Linux — and the limits of a product attestation​

There are two practical reasons Microsoft began with Azure Linux when publishing machine‑readable VEX attestations:

• Scope and scale: Microsoft chose a phased rollout for CSAF/VEX starting with Azure Linux because it is a single, well‑bounded set of artifacts that Microsoft maintains and distributes as Linux images. That makes the initial inventory manageable and yields immediate, actionable guidance for a clear set of customers.
• Actionability: explicitly naming Azure Linux gives Azure customers a direct remediation path and reduces noisy uncertainty across the ecosystem; when Microsoft declares a product “Known Affected,” customers can prioritize updates quickly.

However, the product‑scoped attestation has limits:

• It does not provide exhaustive coverage of all Microsoft‑distributed kernels or images.
• Two Microsoft kernel artifacts built from different source trees and build configs may include different drivers and different upstream commit ranges; the presence of a vulnerable upstream file is an artifact build‑time property, not an inevitability across all Microsoft artifacts.

---

Critical analysis — strengths, practical risks, and recommendations​

Strengths of Microsoft’s approach​

• Clarity for Azure Linux customers: naming Azure Linux reduces ambiguity and accelerates remediation for a defined customer set.
• Machine‑readable attestations (VEX/CSAF): these enable automation and integration into enterprise vulnerability workflows, reducing time‑to‑remediate at scale.

Practical risks and gaps​

• Inventory completeness lag: Microsoft’s phased VEX rollout necessarily leaves gaps while other products are inventoried; customers cannot infer safety from the absence of attestations. Several community analyses stress that absence of attestation = absence of evidence, not evidence of absence.
• Surface area of Microsoft artifacts: Microsoft ships or maintains multiple Linux kernel artifacts (WSL2 kernels, linux‑azure kernels, curated Marketplace images, AKS node images). Each is a candidate for containing the same upstream code depending on build choices. Operators with mixed Microsoft artifacts should not be complacent.
• Operational complexity: kernel updates require reboots and orchestration across cloud fleets and on‑prem hosts; vendors’ backport strategies differ, so mapping “fixed” status to a package name requires careful per‑distro checks.

Recommendations (prioritized)​

• Immediately apply vendor/kernel updates for hosts running mlx5 hardware, especially on Azure Linux images where Microsoft has attested the component.
• For all Microsoft‑provided Linux artifacts in your estate, perform the artifact‑level checks listed above (lsmod, dmesg, kernel config, SBOM/VEX ingestion). Treat non‑attested artifacts as unverified until checked.
• Integrate MSRC CSAF/VEX feeds into your vulnerability‑management pipeline and watch for updates to product mappings. Microsoft’s VEX rollout aims to automate precisely these decisions.
• If SR‑IOV / ECVF vports are used in production, plan change windows to test kernel updates and consider temporary isolation or feature disablement as stopgap measures if vendor guidance permits.
• Keep observability running: log aggregation, kernel panic/oops alerts, and proactive alerting on refcount underflow signatures speed detection of real‑world triggers.

---

Final assessment​

CVE‑2025‑38109 is a kernel‑level availability defect in net/mlx5 with real operational consequences for hosts that load the mlx5 driver and use ECVF/SR‑IOV features. Microsoft’s published position and machine‑readable attestations name Azure Linux as the Microsoft product Microsoft has inspected and found to include the vulnerable upstream component; that attestation is authoritative and should be actioned for Azure Linux hosts immediately.
But do not treat that attestation as a global exclusion of all other Microsoft artifacts: other Microsoft‑distributed kernel binaries and images may or may not contain the same mlx5 driver and vulnerable commit ranges, and those artifacts must be verified by operators and trust‑owners. The correct operational posture is dual: (1) act on Microsoft’s explicit Azure Linux attestation now, and (2) run artifact‑level verification and remediation across any other Microsoft kernels, images, or appliances you run until they are explicitly attested or proven not affected.

---

Quick reference — key facts at a glance​

• Vulnerability: CVE‑2025‑38109 — net/mlx5: Fix ECVF vports unload on shutdown flow.
• Symptom: refcount_t underflow and UAF during mlx5 vport/ECVF shutdown; kernel oops.
• Microsoft attestation: Azure Linux is the Microsoft product Microsoft currently declares as “potentially affected.”
• Does Azure Linux = the only possible Microsoft carrier? No — technically other Microsoft kernels or images could include mlx5; verify artifact by artifact.
• Action: patch kernels per vendor advisories; verify other Microsoft artifacts using SBOM/VEX/inspection; monitor kernel logs.

---

Every technical inventory decision you make about this CVE should be evidence‑driven: run the checks above, use vendor advisories to map fixed packages to your distributions, and ingest Microsoft’s CSAF/VEX attestations where available to automate decisions for Azure Linux images. If you manage a mixed estate that includes WSL2 clients, Azure Marketplace images, AKS, or other Microsoft‑distributed artifacts, assume “unverified” until you can demonstrate otherwise — and prioritize hosts that run mlx5 hardware and SR‑IOV/ECVF features for immediate patching.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center