Linux Kernel PTP One-Step Leak Fixed CVE-2025-38148

A small, surgical change to the Linux kernel’s MSCC PHY PTP code closes a subtle but operationally important memory leak that could quietly consume kernel memory on systems that use one‑step hardware timestamping. The fix—recorded as CVE‑2025‑38148—ensures that frames for which the NIC hardware inserts the transmit timestamp (one‑step timestamping) are freed promptly instead of lingering in kernel queues indefinitely. The vulnerability is primarily an availability and resource‑management issue, not a remote code‑execution or privilege‑escalation vector, but it matters in embedded appliances, telecom gear, and any system that exposes hardware PTP functionality to guests or low‑privileged workloads.

Background / Overview​

One‑step timestamping is a PTP (Precision Time Protocol) mode where the network interface controller (NIC) hardware inserts the exact transmit time into the outgoing frame so the stack does not have to compute or attach it later. In that mode the driver should not continue to hold on to the socket buffer (skb) for later timestamp completion, because the hardware will not generate the usual transmit completion interrupt that the driver uses to release the skb.
A code path in the MSCC PHY PTP driver failed to take that into account. When one‑step syncing was enabled the driver kept the skb waiting for an interrupt that never arrives, which left the frame allocated and unreleased. Under sustained traffic or repeated operations this results in a progressive kernel memory leak that can lead to degraded performance or even out‑of‑memory conditions on long‑running systems. The issue was assigned CVE‑2025‑38148 and fixed upstream with a minimal change that frees the skb in the one‑step timestamping case. This change and its stable backports are part of the kernel’s normal maintenance streams.

---

Technical anatomy: what went wrong​

The design intent of one‑step timestamping​

In normal (two‑step) timestamping the driver hands a packet to the NIC and waits for the hardware to assert that the packet was transmitted; an interrupt or completion callback then supplies the exact timestamp and the driver can hand that back to user space. In one‑step timestamping the NIC itself inserts the transmit timestamp into the packet while transmitting it; there is no separate completion event containing the timestamp. Therefore, well‑behaved drivers should not hold a reference to the skb waiting for a later timestamp event when one‑step is in use. Instead they should release the skb immediately after handing it to the hardware.

The bug​

The MSCC PHY driver’s PTP transmit path failed to release the skb in the one‑step case. Because the hardware will not return a timestamp interrupt for such frames, the driver’s normal release path never executes and the skb remains allocated. This is a classic resource‑leak bug: the code did not free an allocation on a particular, valid execution path. Over time and repeated triggers the unreleased skbs accumulate in kernel memory, increasing the kernel’s memory footprint and risking service degradation or an OOM condition. The vulnerability is not a memory corruption or arbitrary‑write primitive; it is a lifecycle/cleanup omission that affects availability.

A compact upstream fix​

Upstream maintainers fixed the defect with a targeted change: when the code detects one‑step timestamping is configured for a transmit frame it now frees the skb immediately instead of waiting for a completion callback that will never occur. The patch is intentionally narrow — it removes the leak without altering the broader PTP architecture or behaviour for two‑step timestamping. The change was recorded in the kernel stable trees and mapped into distribution updates. The Linux kernel CVE announcement and stable commit records list the relevant commit IDs and the single affected driver file (drivers/net/phy/mscc/mscc_ptp.c).

---

Affected code, versions, and distribution mapping​

• Affected component: Linux kernel, MSCC PHY PTP code (drivers/net/phy/mscc/mscc_ptp.c).
• Introduced: the problematic behavior traces to an earlier change introduced in the 5.9 development line (the kernel CVE announcement maps the introduction to a specific commit).
• Fixed: the upstream remedy landed in multiple stable branches; stable commits are recorded for 6.1.142, 6.6.94, 6.12.34, 6.15.3 and 6.16-rc1 (and equivalents in vendor backports). Administrators should map the fix by commit ID rather than by relying solely on a kernel version number.
• Distribution advisories: Debian, Ubuntu, SUSE, Oracle Linux, and other vendors have ingested the CVE and published package mappings and severity guidance. CVSS v3 has commonly been represented as 5.5 (medium), modeling the bug as a local, availability‑impact flaw. These mappings show which packaged kernel versions include the upstream fix and which still require updates.

Practical note: embedded images, SoC BSPs, and vendor kernels often lag upstream. Those environments frequently use in‑tree or vendor‑forked drivers and may not receive timely backports; as a result many industrial and telecom appliances remain the highest‑priority population for remediation.

---

Risk and exploitability analysis​

Impact​

• Primary impact: Availability. The leak can quietly grow the kernel’s allocated skb pool, increasing memory pressure and, in extreme cases, provoking OOM kills or otherwise degraded service. The bug does not, by itself, provide a means to execute arbitrary code or raise privileges.
• Exploitability: Local. An attacker needs the ability to submit packets or trigger operations that exercise the MSCC PHY PTP transmit path with one‑step timestamping enabled. In many deployments this requires local access or control of a workload that can configure or use PTP functionality. For cloud multi‑tenant hosts where NICs and PTP are exposed to guests the risk is higher than for isolated desktops.
• Likelihood of remote abuse: Low. This is not a network‑service remote execution vector. Weaponizing a leak into a sustained denial of service requires repeated interactions and a path to exercise PTP one‑step transmit behavior. That said, attackers seeking to degrade services can use local primitives when they are available.

Operational severity​

Several vendor trackers and CVE aggregators characterize the bug as moderate or medium severity (CVSS 5.5 in many vendor mappings), reflecting its local attack vector and availability impact. For systems where PTP/hardware timestamping is required — for example telecom gear, timing appliances, or precision timestamping servers — the practical risk rises because the vulnerable path may be exercised frequently as part of normal operation. In contrast, general desktop/server images that do not build or enable the MSCC PHY code are less likely to be affected.

Why the fix is low‑risk but necessary​

The upstream change is deliberately tiny and defensive: free the skb in the one‑step case. That minimal surface reduces the risk of functional regressions while eliminating the memory leak. For this reason the patch is straightforward to backport into stable kernels and to roll into vendor updates. Still, the long‑tail of vendor kernels means operators must verify their specific packages rather than assuming an environment is remediated because a generic distro announced a fix.

---

Detection and monitoring guidance​

Detecting this specific leak requires looking for resource signals rather than a single error message. The MSCC PHY one‑step leak will not necessarily produce an explicit stack trace or oops until memory pressure becomes severe.

• Check PTP / timestamping capability per interface:
• Query the interface’s timestamping support (for example with the ethtool timestamping display) to see if hardware one‑step modes are enabled or exposed.
• Monitor kernel memory and skb usage:
• Use slabtop, free, vmstat, or system memory telemetry to watch for unexplained kernel memory growth on systems that run PTP heavy workloads.
• Watch for increasing counts of skbs or backlog queues associated with the interface driver.
• Look for long‑running processes or workloads that perform frequent timestamped transmits; correlate that activity with memory growth.
• Enable kernel memory diagnostic tooling in test environments:
• kmemleak can help reveal leaked kernel allocations if enabled and scanned.
• For development and staging kernels, KASAN or additional allocators/sanitizers can surface missing free events; those tools are impractical in production but invaluable during triage.
• Vendor and distribution advisories sometimes include package‑level mapping. Confirm the kernel package changelog includes the upstream commit ID(s) referenced by the Linux CVE announcement to determine whether a host is patched.

Flag: there is no specific, globally consistent dmesg text that uniquely signals this leak. Detection is therefore behavioral and inventory‑driven.

---

Mitigation and remediation steps​

• Patch: apply vendor or distribution kernel updates that include the upstream fix.
• Preferred remediation is to update the kernel package supplied by your vendor. Confirm the package changelog or security advisory lists the upstream commit ID(s) that resolve CVE‑2025‑38148 or explicitly references the CVE. Reboot into the updated kernel.
• If an immediate kernel update is not possible:
• Disable hardware PTP/one‑step timestamping on affected interfaces where possible. Use interface configuration and driver settings to avoid one‑step transmit modes; consult your NIC vendor or driver documentation for precise controls.
• If PTP is not used, disable PTP support entirely on the host or on the interface to prevent exercising the vulnerable path.
• For devices where the MSCC PHY driver is a module, consider unloading or blacklisting the module as a short‑term mitigation if doing so does not disrupt required network functionality.
• Operational controls:
• Limit which workloads or tenants can configure or use PTP features, particularly on multi‑tenant hosts.
• Increase monitoring of kernel memory metrics and skb counts for early warning signs.
• Long term:
• For embedded and OEM images, coordinate with vendors to obtain backported fixes or updated BSP/kernel images; do not assume general distro updates cover custom vendor kernels.

Note: Avoid backporting or cherry‑picking random kernel commits into production kernels unless you have kernel maintenance expertise. The canonical recommendation from the Linux kernel team is to apply full, stable kernel updates or vendor backports that include the tested fixes. The kernel CVE announcement lists the authoritative commit references for administrators that must port fixes manually.

---

Practical checklist for administrators​

• Inventory phase:
• Determine whether the host’s kernel build includes the MSCC PHY driver and whether the PTP/Timestamping feature is enabled.
• Look for driver presence via module listings and kernel config (for example, module lists and /boot/config-$(uname -r) where available).
• Triage phase:
• Check vendor advisories (Debian/Ubuntu/SUSE/Oracle/your Linux vendor) for packaged updates that map to CVE‑2025‑38148. If the advisory lists fixed package versions, plan the package update and reboot.
• If vendor updates are not yet available for your image, determine whether PTP is used on the host. If not used, disable it pending an update.
• Remediation phase:
• Apply kernel package updates that contain the stable commit(s) resolving CVE‑2025‑38148 and reboot.
• Validate post‑patch behavior: confirm timestamping still works for intended modes, and verify there is no abnormal kernel memory growth.
• Verification:
• Confirm the kernel changelog or package metadata contains the upstream commit IDs referenced by the kernel CVE announcement; this is the reliable way to ensure the fix is present.

---

Why this matters beyond the immediate fix​

Memory‑management bugs like this one are often low on the CVE drama scale compared with RCE or privilege escalation, but they matter for real operations. Appliances and embedded devices frequently run for years without comprehensive updates; a leak that is exercised constantly in such a device will slowly degrade service and can be used as a denial‑of‑service primitive. In multi‑tenant and virtualization environments, small local primitives can become higher‑value attack tools when they let untrusted tenants nudge host health indicators.
At the same time, the narrowly scoped, defensive nature of the upstream fix means the remediation is low‑risk and practical to deploy. That combination of low implementation risk and real operational impact is exactly the scenario where administrators should move quickly: apply vendor patches and, if necessary, implement temporary configuration changes to disable the affected feature until the kernel update is installed.
Operational practitioners who monitor kernel memory health, keep a clean patch backlog, and apply vendor advisories promptly will find this CVE straightforward to remediate. Operators who rely on slow‑moving BSPs or vendor images should treat this as a reminder to maintain an accurate inventory of kernel components and to demand timely backports from suppliers.

---

Strengths and potential unintended consequences of the fix​

• Strengths:
• The upstream patch is minimal and purpose‑built: it closes a single missing‑free path and does not change PTP semantics for other modes.
• Minimal risk of regression because the behavior change applies only when one‑step timestamping is in use.
• The fix is easy to backport and has been included across stable kernel trees and vendor advisories, enabling broad remediation.
• Potential risks and caveats:
• Administrators who backport the commit manually must do so carefully. Kernel commits interact with local configuration and vendor modifications; incorrect backports can cause regressions.
• Disabling PTP as a mitigation can have real operational impact in environments that rely on precise time synchronization. Any mitigation that turns off one‑step timestamping should be weighed against the timing requirements of the deployment.
• Vendor kernels or embedded images may not receive the fix promptly; operators should verify vendor statements rather than assuming a generic distro advisory covers all images.

When in doubt, prefer vendor‑supplied kernel packages and formal backports over ad‑hoc local cherry‑picks of upstream commits.

---

Final takeaways​

CVE‑2025‑38148 is a textbook example of a low‑complexity, operationally meaningful kernel bug: a missing free on a valid code path that surfaces only under specific hardware and configuration (one‑step PTP transmit). It offers a straightforward, low‑risk remediation path (apply the upstream patch via vendor kernel updates), but it also highlights the long tail of embedded and vendor kernels that can keep even small bugs alive in production for months.
Administrators should:

• Inventory hosts for MSCC PHY/PTP support and one‑step timestamping exposure.
• Apply vendor kernel updates that include the upstream fix as a priority for affected systems.
• Use configuration mitigations (disable PTP or one‑step timestamping where appropriate) when immediate patching is not possible.
• Monitor kernel memory and skb allocations in environments where PTP is used heavily.

The kernel patch and vendor advisories are available and straightforward to apply; this CVE should be treated as an important maintenance item for timing‑sensitive and embedded network platforms.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center