CVE-2025-38126: Linux STMMAC PTP Division by Zero Patch

The Linux kernel vulnerability tracked as CVE-2025-38126 is a narrow but important robustness bug in the STMMAC Ethernet driver: under certain board or device-tree configurations the driver can end up with a zero PTP clock rate (ptp_rate / clk_ptp_rate), and that zero value may be used during PTP timestamp initialization — producing a division‑by‑zero in kernel space and a kernel oops or panic. This article explains what changed, who is affected, how to detect exposure, the practical threat model, recommended mitigations and patch guidance, and a measured assessment of Microsoft’s public attestation and the broader distribution landscape.

Background / Overview​

The defect exists in the STMicroelectronics stmmac driver (drivers/net/ethernet/stmicro/stmmac). Some platform drivers obtain the PTP clock rate (clk_ptp_rate) from device-tree or a clock lookup and do not always open‑code or validate the returned value. Because clk_get_rate may return 0 on some boards or configurations, that 0 value can propagate into PTP initialization logic. When the code later uses the ptp clock rate in arithmetic for timestamp counter setup, a division by zero occurs, causing an immediate kernel fault (Ldiv0_64) and likely a kernel panic in the affected context. This is a stability/availability issue rather than a remote code‑execution vulnerability. Short, concrete summary of the fixed behavior:

• The upstream fix adds a defensive check to ensure that the PTP (clk_ptp_rate) value is not zero before using it to configure timestamping.
• If the value is zero, the code now returns an error and logs the condition instead of performing the arithmetic that would trigger a divide‑by‑zero.

---

Why this matters (technical and operational impact)​

Technical anatomy — where the crash happens​

When an stmmac device opens and PTP/timestamping is configured, the driver calls stmmac_init_tstamp_counter (or related PTP init routines) and performs timing arithmetic that divides by the PTP clock rate. If clk_get_rate returned 0 earlier (for example, due to clocks not being enabled at probe time or platform quirks), the division will fault. The resulting call trace observed in real-world reports shows Ldiv0_64 originating from stmmac_init_tstamp_counter and a chain back to the network device open/initialization path — meaning the kernel will crash as part of normal device bring‑up.

Practical impact and attack surface​

• Primary impact: availability (kernel oops / panic). The bug does not itself enable arbitrary code execution or privilege escalation.
• Where it matters: embedded boards, IoT gateways, telecom or industrial devices using STMicroelectronics MACs, SoC BSPs, and Linux images that build the stmmac driver. Cloud images or VM kernels that include STMMAC support and expose PTP functionality (rare in typical cloud VM scenarios but possible for some marketplace images or specialized appliances) are also in scope.
• Exploitation model: the operator or an untrusted workload (in multi‑tenant contexts) that can trigger interface bring‑up or PTP initialization can cause the fault. It is not a remotely exploitable network service bug by default — local or guest-level actions are needed to reach the vulnerable code path.

---

What was changed (upstream fix and where it landed)​

Upstream kernel stable trees received a small, surgical patch that adds an explicit check for a zero ptp/clk rate before performing timestamp arithmetic, and logs an error and returns if the rate is invalid. The Linux kernel CVE announcement lists the affected files (drivers/net/ethernet/stmicro/stmmac/stmmac_main.c and drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.c) and references multiple stable commit IDs that implement the remedy. The fixes were merged across several stable branches (examples called out by the kernel CVE message include fixes in 6.1.142, 6.6.94, 6.12.34, 6.15.3 and a 6.16-rc1 patch reference). Administrators should apply the appropriate stable kernel update for their branch or port the single commit if they are maintaining a custom kernel. Key upstream commit references (as included in the kernel announcement):

• commit 32af9c289234990752281c805500dfe03c5b2b8f (stable branch mapping)
• commit b263088ee8ab14563817a8be3519af8e25225793
• commit bb033c6781ce1b0264c3993b767b4aa9021959c2
• commit 379cd990dfe752b38fcf46034698a9a150626c7a
• commit 030ce919e114a111e83b7976ecb3597cefd33f26

(These commit IDs are the authoritative pointers to the patch diffs in stable git trees and appear in the upstream CVE announcement.

---

Cross‑verification and sources​

This analysis cross‑checked multiple independent and authoritative sources:

• National Vulnerability Database (NVD) — published CVE-2025-38126 description.
• Linux kernel CVE announcement / linux‑cve‑announce (Greg Kroah‑Hartman’s notice and the stable commit mapping).
• OSV / public vulnerability trackers and distribution vulnerability databases (Debian / Red Hat / SUSE / Cvedetails / Rapid7 summaries) that indexed the CVE and referenced the same symptoms and upstream fixes.
• Stable patch emails and stable branch lists showing the merged commits and backport patches.

All of the above converge on the same technical facts: the root cause is an unchecked zero ptp_rate/clk_ptp_rate, the symptom is a division‑by‑zero in timestamp initialization, and the upstream remedy is a small defensive check. Where possible, prefer to verify your distribution kernel changelog or package metadata against the commit IDs above rather than relying on generic kernel version numbers.

---

Who should worry — exposure matrix​

• High priority (patch immediately):
  • Embedded devices and SoC images that use STMicroelectronics MACs and stmmac driver (e.g., STM32 platforms). These devices often use platform DT and clock trees that can produce zero clk rates under certain initialization orders.
  • Multi‑tenant virtualization or appliance hosts that enable hardware PTP timestamping or expose device configuration to guest workloads.
• Medium priority:
  • Cloud images and marketplace appliances that include STMMAC in the built kernel. Microsoft’s public attestation identified Azure Linux as an image family that includes the affected code for many similar kernel CVEs; Azure Linux customers should treat Microsoft’s attestation as authoritative for that product family and update accordingly. However, absence of additional Microsoft product names from their attestation does not prove other Microsoft artifacts are safe — manual inventory is required for WSL kernels, linux‑azure kernels, custom Marketplace images, and partner images.
• Lower priority:
  • Generic desktop and server images that do not build the stmmac driver into the kernel or do not enable PTP in their kernel config.

---

Detection and triage steps (operational checklist)​

Short checklist to get a deterministic answer about whether a host is affected:

1. Identify the running kernel:
   • uname -a
2. Check whether the stmmac driver is present:
   • lsmod | grep stmmac
   • modinfo stmmac (if module)
3. Inspect kernel config for PTP/EST/stmmac options:
   • zcat /proc/config.gz | grep -Ei 'STMMAC|PTP|PTP_RATE|TIMESTAMP'
   • grep -i stmmac /boot/config-$(uname -r) (if /boot/config-* is present)
4. Check for PTP devices and timestamping exposure:
   • ls /sys/class/ptp
   • ethtool -T <interface> (show timestamping/capabilities)
5. Search kernel logs for the crash signature (example):
   • journalctl -k | grep -E 'Ldiv0|stmmac_init_tstamp_counter|stmmac'
   • dmesg | grep -E 'Ldiv0|stmmac'
6. Map kernel package to upstream commit:
   • Consult your distro’s security tracker or package changelog and verify whether the upstream stable commit IDs referenced by the kernel CVE announcement are present in the packaged kernel. If you cannot find a mapping in the vendor changelog, treat the package as unconfirmed.

If any check indicates the stmmac driver is present and the kernel predates the stable commits above, plan remediation.

---

Short‑term mitigations (when patching is delayed)​

If you cannot apply a kernel update immediately, the following mitigations reduce exposure:

• Disable PTP/timestamping at the interface level if it is not required:
  • Use ethtool to disable hardware timestamping or related features (consult your NIC docs; behavior varies by platform).
• Isolate affected hosts:
  • Prevent untrusted tenants, CI runners, or guest workloads from performing actions that trigger device bring‑up or PTP configuration. Restrict access to sysfs nodes that expose PTP configuration to non‑privileged users.
• Monitor for symptoms:
  • Centralize kernel logs, enable persistent journal or kdump to capture an OOPS or vmcore if a crash occurs.
• For embedded or appliance vendors:
  • Contact your device vendor for an updated BSP/kernel or backport the small defensive commit into your maintained kernel branch. The patch is intentionally minimal and designed to be low‑risk when backported.

Note: these are mitigations for availability; they will not “fix” the kernel arithmetic error — only prevent the code path or reduce the chance of triggering it until a kernel update is applied.

---

Recommended remediation path (step‑by‑step)​

1. Inventory: determine which devices/images in your estate include the stmmac driver and whether PTP is enabled. Automate this using image scanning and kernel config inspection where possible.
2. Map: for each kernel package, consult your distro’s security tracker or the vendor advisories and check whether the stable commit IDs referenced for CVE‑2025‑38126 are present in the package changelog.
3. Patch: apply the vendor-supplied kernel updates that include the upstream commit backport, or update to a kernel release that contains the fix. For custom kernels, apply the commit from the stable tree and rebuild. The kernel CVE announcement lists the commit IDs and the stable branches where the change landed — use those as authoritative references.
4. Reboot into patched kernel and validate: after reboot, exercise device bring‑up and timestamping code paths in a staging environment to confirm the kernel no longer faults. If you previously observed an Ldiv0_64 trace, reproduce the same test and confirm the error is handled gracefully or logs an error instead of triggering a divide‑by‑zero.
5. Automate: ingest vendor CSAF/VEX outputs (or your distro’s security feeds) into vulnerability management so future attestations and expanded vendor mappings are automatically applied. Microsoft’s attestation practice for Azure Linux is an example of a machine‑readable signal that can be automated; however, it is product‑scoped, and other Microsoft artifacts may not yet be attested — you must inventory and verify them separately.

---

Microsoft’s attestation and scope — what to know (analysis and caveats)​

Microsoft’s Security Response Center (MSRC) publishes product‑scoped attestations (CSAF/VEX) that indicate where they have completed inventory for particular product families (for example, Azure Linux images). In recent disclosures Microsoft has explicitly attested that certain Azure Linux images include particular upstream components and therefore are potentially affected; that provides a clear remediation signal for Azure Linux customers. However, that attestation is not a universal statement for every Microsoft kernel artifact — other Microsoft kernel artifacts such as WSL2 kernels, linux‑azure builds, Marketplace images, or partner appliance images may or may not include the same code and are separate build artifacts. Absence from the attestation does not prove absence from your environment. Operators should therefore verify the kernel build/config in every Microsoft‑supplied image they run rather than assuming safety from the VEX statement alone.
Concretely:

• If you run Azure Linux images and Microsoft has published a VEX/CSAF attestation naming Azure Linux for this CVE, treat that as an authoritative remediation signal and apply the patched image/kernel Microsoft publishes.
• If you run other Microsoft artifacts (WSL2, custom Marketplace images, linux‑azure, partner images), you must still perform the kernel/config checks described above and apply appropriate updates or vendor backports if the stmmac driver is present.

---

Strengths and risks in the upstream and vendor responses​

Strengths:

• The upstream fix is small, targeted, and low risk: an explicit check that prevents a division‑by‑zero and logs the problem. This makes it straightforward to backport into stable branches and vendor kernels without broad regression risk.
• Multiple distributors and vulnerability trackers have indexed the CVE and mapped it to the stable commits, enabling standard update channels to deliver the remedy to most users.

Remaining risks and caveats:

• Long tail of unpatched devices: embedded devices, OEM BSPs, and vendor‑forked kernels often lag upstream fixes and may remain vulnerable for months. Administrators should press vendors for backports if production devices are affected.
• Attestation scope confusion: vendor or cloud attestation naming a single product family (e.g., Azure Linux) is a valuable automation signal, but it is product‑scoped — customers must not assume that other artifacts are covered unless the vendor explicitly states so. Treat “not listed” as “not yet attested,” not “safe.”
• Detection limitations: kernel oops traces may be lost on reboot unless you capture logs or vmcores. Centralized logging and crash capture (kdump/vmcore) are essential for forensic validation if you suspect an incident.

---

Recommended prioritization for enterprises​

1. Patch embedded appliances and SoC boards that use STMMAC and expose PTP — these are highest priority because device bring‑up often occurs automatically and may be triggered by local inputs.
2. Patch cloud images where a vendor (e.g., Microsoft Azure) has published a remediation for attested images — treat vendor attestation as authoritative for the named image family and update accordingly.
3. Inventory WSL2, linux‑azure kernels, Marketplace images and partner appliances — do not assume they are unaffected; validate kernel builds and apply vendor patches or backports where needed.
4. For hosts where immediate patching is impossible, apply mitigations (disable PTP/timestamping, isolate hosts, enable crash collection), then schedule backports or kernel upgrades.

---

Final assessment and closing thoughts​

CVE‑2025‑38126 is a classic kernel robustness defect: trivial to explain, trivial to fix, but potentially disruptive in environments where the vulnerable code path is exercised. The upstream response is correct and timely: a small defensive check was merged to stable branches and distribution trackers have mapped the change into vendor advisories. The technical severity is centered on availability (division‑by‑zero leading to kernel oops), not remote exploitation, but the operational consequences can be serious for multi‑tenant hosts, embedded appliances, and production infrastructure that relies on stable kernel uptime.
Enterprises should:

• Treat this as a patch‑and‑verify item: update kernels (or backport the upstream commit), then validate in staging that PTP initialization no longer triggers an Ldiv0_64 trace.
• Automate ingestion of vendor CSAF/VEX outputs and distribution trackers, but do not rely solely on a single vendor’s attestation to decide scope — inventory every kernel artifact in your estate.
• If patching cannot be immediate, apply targeted mitigations (disable PTP where unnecessary, isolate at‑risk hosts, enable persistent logging and vmcore collection).

The fix is small, the verification steps are straightforward, and the best course is pragmatic: identify affected artifacts, schedule kernel updates, and remove the long‑tail risk from unmanaged vendor images and embedded devices.

---

Conclusion
This CVE reinforces a perennial lesson for kernel maintainers and operators alike: subtle platform assumptions (like assuming a clock rate will never be zero) can become stability liabilities when code runs on the wide variety of device trees and BSPs in the real world. The upstream remedy is small and safe; the operational work is inventory and timely deployment. Apply the patch where needed, verify the fixes in your environment, and use vendor attestations as one automation signal among several in a comprehensive patch‑management workflow.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center