CVE-2025-39859

What it actually does

Race condition in ptp_ocp_detach allows the watchdog timer handler to access a ptp_ocp structure after devlink_free has deallocated it, causing a use-after-free.

Why it matters to the business

Systems using PTP OCP hardware may experience kernel instability, crashes, or potential local privilege escalation during device removal or driver unload, with moderate urgency due to low EPSS and absence from KEV lists.

How an attack unfolds

An attacker with local access triggers concurrent ptp_ocp_remove and ptp_ocp_watchdog execution; the timer handler dereferences freed memory after the detach path skips timer_delete_sync when the handler is already active.

How to fix it

Upgrade the Linux kernel to the commit f10d3c7267ac7387a5129d5506c3c5f2460cfd9b or later stable releases that unconditionally call timer_delete_sync in ptp_ocp_detach.

How to confirm the fix worked

Verify the presence of commit f10d3c7267ac7387a5129d5506c3c5f2460cfd9b in the running kernel source; exercise ptp_ocp attach/detach paths under load and confirm no timer-related UAF warnings in kernel logs.

Typical attack path

1. Obtain local code execution on a system exposing ptp_ocp devices
2. Trigger device removal or module unload while the watchdog timer is armed
3. Win the race so the handler runs after devlink_free but before any synchronization
4. Access the dangling bp pointer to achieve use-after-free read or write

How to detect it

Inspect kernel logs for use-after-free warnings or KASAN reports referencing ptp_ocp_watchdog or devlink_free; correlate with ptp_ocp module load/unload events.

What your security team should do

• Prioritize kernel updates on any hosts exposing ptp_ocp hardware within standard change windows
• Monitor upstream stable branches for backports of the timer synchronization fix
• Review device removal code paths in similar timer-using drivers for analogous races