CVE-2025-38125: Linux STMMAC Patch and Azure Linux Attestation

The Linux kernel fix tracked as CVE-2025-38125 corrects a simple but dangerous logic error in the STMMAC Ethernet driver: if the driver’s recorded ptp_rate is zero, that bogus value can be propagated into the EST configuration and cause a division‑by‑zero. Microsoft’s public advisory names Azure Linux as a product that “includes this open‑source library and is therefore potentially affected,” but that phrasing is a product‑scoped attestation rather than a blanket guarantee that no other Microsoft artifacts ship the same code — operators must still inventory and verify their own kernels and images.

Background / Overview​

CVE-2025-38125 is a kernel robustness bug introduced in the STMMAC Ethernet driver (drivers/net/ethernet/stmicro/stmmac). The defect is straightforward: when the driver’s previously recorded ptp_rate happens to be zero, the code later uses that value while configuring EST (Enhanced Scheduled Traffic), which can result in a division‑by‑zero and a kernel crash or panic. Upstream maintainers fixed the problem by adding a defensive check and returning an error instead of allowing the zero value to be used. This is an availability/stability issue, not a remotely wormable code‑execution flaw. Public trackers and downstream advisories classify it accordingly: the practical impact is kernel oopses, device crashes, or denial‑of‑service in hosts that load the vulnerable driver and reach the EST configuration path. Many distributions have mapped the upstream commits and have published fixes in their kernel-stable trees. Why operators should still care: in multi‑tenant cloud environments or on hosts running lots of virtual guests and network control plane code, a kernel crash triggered from a narrow driver path can still produce significant operational disruption. The risk profile is therefore “availability impact, medium exploit complexity, local or privileged actor” rather than “remote arbitrary code execution.”

---

What Microsoft actually said — and why the wording matters​

The MSRC attestation line​

Microsoft’s public guidance for a number of upstream open‑source CVEs has recently followed a consistent pattern: rather than publishing single‑line advisories for every Microsoft product, Microsoft has begun publishing machine‑readable CSAF/VEX attestations for specific product families, starting with Azure Linux. In the advisories Microsoft has published, you will often see the phrase that “Azure Linux includes this open‑source library and is therefore potentially affected,” followed by a commitment to update the CVE/VEX entries if other Microsoft products are found to ship the same component. That is exactly what appears in the discussion for this and several similar kernel CVEs.

How to interpret that sentence​

Read the MSRC sentence like this:

• It is an authoritative attestation that Microsoft has completed inventory for the Azure Linux product family and found the upstream component in those builds. Treat that as a definitive signal for Azure Linux images and packages.
• It is not an implicit guarantee that no other Microsoft product includes the same upstream source files. Absence of other Microsoft product names from the attestation means those other artifacts haven’t been publicly attested yet, not that they were exhaustively checked and declared free. Microsoft explicitly commits to expand the mapping if additional internal SKUs are discovered to include the component.

This distinction matters operationally: Microsoft ships multiple Linux kernel artifacts (for example, the linux‑azure kernel used in some VM images and the kernel used by WSL2), and each is a separate build with its own kernel configuration. Whether a given Microsoft image is affected depends on whether that kernel build included the STMMAC driver and the EST/PTP code paths. A product-level VEX entry is a valuable automation signal — but it is only a signal for the attested product family.

---

Is Azure Linux the only Microsoft product that includes the affected code?​

Short answer: No — Azure Linux is the only Microsoft product Microsoft has publicly attested as including the affected STMMAC code so far, but that does not preclude other Microsoft images or kernels from containing the same upstream driver. Absence of public attestation is not proof of absence.
Longer explanation:

• Microsoft’s published CSAF/VEX statements identify which product families the company has completed inventory for. For CVE‑2025‑38125 Microsoft has attested Azure Linux as a carrier; that means Azure Linux customers have a direct, machine‑readable remediation/triage signal they can automate.
• However, Microsoft also maintains other Linux kernel artifacts that it ships or uses internally: WSL (Windows Subsystem for Linux) kernels, linux‑azure builds for VM guests, Marketplace images, and possibly appliance or partner images. Each kernel artifact may be built with different CONFIG_* switches and may or may not include the STMMAC driver or the EST/PTP code path. Whether those artifacts are affected is a per‑artifact question, not a vendor‑wide boolean.
• Independent trackers and distribution advisories (Debian, Ubuntu, the Linux kernel mailing list) confirm the defect and point to the upstream commits that remedied it; those independent mappings show which kernel branches and package versions are vulnerable or fixed. They provide the technical evidence for remediation beyond Microsoft’s attestation. Use them to cross-check your kernels.

In short, Azure Linux customers should act immediately on Microsoft’s attestation; operators running other Microsoft images need to verify their artifacts rather than assume they are unaffected.

---

Technical deep dive: what the patch changed​

The vulnerable code lives in drivers/net/ethernet/stmicro/stmmac/stmmac_est.c. The problem was a missing sanity check: the driver recorded a ptp_rate earlier, but did not verify it was non‑zero before using it to calculate EST timing parameters. The upstream patch adds a simple check and returns an error if ptp_rate is zero, preventing a division‑by‑zero during EST configuration. The kernel CVE post and the stable commit log list the exact submitted patches and the affected file. Why that matters in practice: PTP (Precision Time Protocol) interacts with traffic scheduling when you use time‑synchronized scheduled traffic features. A malformed ptp_rate value leads to invalid timing arithmetic which, in kernel space, can be catastrophic — the kernel cannot safely continue if core scheduler math goes wrong. Fixing the check prevents the crash and ensures the driver fails gracefully when the PTP rate is not known or is invalid.

---

Cross‑checking the claim: verification against independent sources​

To avoid single‑source dependence, verify the CVE and the fix across at least two independent trackers:

• NVD / NIST lists the CVE record and description summarizing the division‑by‑zero problem.
• The Linux kernel CVE announcement and the linux‑cve‑announce mailing list record the affected file path and point to the upstream stable commit(s) that implement the fix. Those commit links are the canonical upstream record and should be used to verify which kernel releases include the remedy.
• Distribution trackers (Debian, Ubuntu) list which kernel package versions were vulnerable and which versions received fixes; these pages are authoritative for downstream packaging and backport status. Use them to determine whether your distribution kernel packages are fixed.

Those independent sources converge on the same technical facts: the defect causes a division‑by‑zero in EST configuration when ptp_rate is zero, and small upstream patches were merged to address it.

---

Practical checklist — how to determine exposure in Microsoft environments​

Operators responsible for Windows and Azure stacks should follow a short verification and remediation plan. The goal is to answer two questions: (A) Do I run any kernel image that contains the vulnerable STMMAC/EST code? (B) If so, have I applied an updated kernel that contains the fix?

1. Inventory Microsoft-provided kernels and images in your estate
   • List Azure VM images and kernels in use (custom images, Marketplace images, Linux distributions).
   • Check WSL2 hosts and the kernel WSL uses (WSL ships a Microsoft‑built kernel by default for some Windows releases).
   • Identify any on‑prem appliances or vendor images that were obtained from Microsoft or that run inside Azure Marketplace images.
2. For each Linux host or image, determine the kernel build and whether the STMMAC driver is present
   • Run uname -a to get the kernel release.
   • Check whether the stmmac driver is present:
     • lsmod | grep stmmac
     • modinfo stmmac (if a module)
     • grep -i stmmac /boot/config-$(uname -r) (to see if CONFIG_STMMAC* options were set)
   • Inspect the kernel config for PTP/EST options that might enable the code path:
     • zcat /proc/config.gz | grep -E 'PTP|EST|STMMAC'
   • If the driver is built into the kernel (not a module), confirm by inspecting /boot/config-<version> or the kernel binary.
3. Map kernel version / commit to known fixed versions
   • Use distribution trackers (Debian, Ubuntu) to see whether your kernel package version includes the fixed upstream commits.
   • If you are running upstream or vendor-modified kernels (linux‑azure, WSL kernel), check vendor advisories and MSRC VEX/CSAF for attestations.
4. If a host is exposed and vulnerable, schedule remediation
   • Apply the vendor kernel update that includes the upstream commit referenced in the CVE advisory.
   • For cloud VMs, use patched images or Microsoft’s provided kernel updates for Azure Linux and linux‑azure images.
   • Reboot the host into the patched kernel.
5. If immediate patching is impossible, mitigate exposure
   • Isolate affected hosts from untrusted tenants or networks where feasible.
   • Disable EST/PTP features in device configuration if they are not required.
   • Limit access to guest actions that can reach the network scheduling or PTP control paths.

This checklist produces a deterministic answer for whether Microsoft-supplied artifacts are affected: check the kernel binary/config and the vendor package mapping rather than relying on whether Microsoft has yet published a VEX entry covering that specific product.

---

Example commands and checks (operational)​

• Kernel and module presence:
  • uname -r
  • lsmod | grep stmmac
  • modinfo stmmac
• Kernel config checks:
  • zcat /proc/config.gz | grep -Ei 'STMMAC|PTP|EST'
  • grep -i stmmac /boot/config-$(uname -r)
• Package mapping (Debian/Ubuntu):
  • apt-cache policy linux-image-$(uname -r)
  • Check your distro’s security tracker for CVE‑2025‑38125 status

If you find the STMMAC driver and a kernel older than the first fixed stable release listed in the upstream commit, treat the host as vulnerable until it’s patched. Upstream commit references appear in the kernel CVE announcement and distribution trackers.

---

Remediation: what to apply and where to look​

• For downstream distributions (Debian, Ubuntu, Red Hat, SUSE): install the kernel update that includes the commits referenced in the kernel stable merge or your distro’s security advisory. Distribution trackers list fixed package versions.
• For Azure Linux customers: rely on Microsoft’s published updates for Azure Linux images (MSRC/VEX and Azure image update guidance). Azure Linux is explicitly attested as including the component, so Microsoft-published fixes and images should be consumed as available.
• For Windows hosts running WSL2: verify the WSL kernel version and whether a Microsoft-supplied WSL kernel contains the driver; for custom WSL kernels, rebuild or replace with a patched kernel. Microsoft’s VEX rollout may include further attestations for WSL over time — but it’s the host operator’s responsibility to verify and patch.
• For Marketplace or partner images: validate the kernel config and package versions inside the image; ask the image vendor for a SBOM or VEX/CSAF attestation if you cannot determine coverage yourself.

---

Strengths and potential risks in Microsoft’s approach​

Strengths​

• Publishing machine‑readable CSAF/VEX attestations for product families (starting with Azure Linux) is a concrete transparency improvement. It gives Azure Linux customers a deterministic, automatable signal to drive triage and patch orchestration. Microsoft has publicly committed to expand VEX coverage and update CVE mappings when more products are identified.

Risks and operational gaps​

• The phased rollout creates a timing window: only the attested product families are machine‑readably confirmed. Other Microsoft artifacts may later be discovered to ship the same component. Customers who assume the vendor statement implies exclusivity risk missing exposures in WSL, linux‑azure kernels, Marketplace images, or vendor appliances. This is a process gap rather than a technical flaw, and it places the burden of verification on the customer for non‑attested artifacts.
• Large vendors ship many distinct kernel artifacts; tracking each one requires consistent inventory automation (SBOMs, VEX ingestion, package and image scanning). Operators who lack that automation will face manual effort and potential blind spots.

---

Final recommendations (prioritized)​

1. Azure Linux customers: treat Microsoft’s attestation as an authoritative signal and apply Microsoft’s patched images or kernel updates as soon as they are available. Automate ingestion of MSRC CSAF/VEX outputs to your vulnerability‑management pipeline.
2. Non‑Azure Linux Microsoft artifacts in your environment (WSL2, linux‑azure, Marketplace images, partner images): do not assume safety. Inspect kernel configuration and package versions as described above, and treat any host with the STMMAC driver and an unpatched kernel as in‑scope for remediation.
3. Use independent trackers to cross‑check fixes: NVD, linux‑cve‑announce, and your distribution’s security tracker (Debian/Ubuntu/Red Hat) list the upstream commit references and package mappings for CVE‑2025‑38125. Cross‑verifying across these sources shortens time‑to‑remedy and reduces blind spots.
4. If you cannot patch immediately: restrict access to interfaces that can exercise EST/PTP configuration, isolate vulnerable hosts from untrusted tenants, and disable EST/PTP if the feature is not required. These mitigations reduce the operational impact until a kernel update is applied.

---

Conclusion​

CVE‑2025‑38125 is a narrow but meaningful kernel robustness bug in the STMMAC driver that can produce a division‑by‑zero during EST configuration when ptp_rate is zero; the upstream patch is small and available in the Linux stable trees. Microsoft’s advisory identifies Azure Linux as a product that includes the implicated code and therefore is potentially affected — a valuable, machine‑readable attestation that gives Azure Linux customers a clear remediation path. However, that MSRC wording is product‑scoped and phased: it tells you what Microsoft has completed mapping for so far, not what Microsoft has exhaustively validated across every internal SKU. Operators running other Microsoft images, kernels, or Marketplace appliances should verify their artifacts directly using kernel config and package mapping, apply the upstream or distributor fixes where needed, and automate VEX/CSAF ingestion to shrink the window between disclosure and remediation.

---

(Technical references used to verify the facts in this analysis include the Linux kernel CVE announcement and stable commits, distribution security trackers (Debian, Ubuntu) listing fixed package versions, and Microsoft’s public CSAF/VEX attestation language for Azure Linux as reflected in MSRC advisory text.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center