CVE-2025-38305

What it actually does

The flaw removes a redundant ptp->n_vclocks check inside ptp_vclock_in_use() under n_vclocks_mux to eliminate a recursive lock acquisition that occurs when n_vclocks_store() and ptp_clock_unregister() race on the same mutex.

Why it matters to the business

Systems performing PTP virtual clock management can experience kernel deadlocks, leading to hangs or crashes that disrupt time synchronization and require reboots, with elevated urgency for organizations running affected LTS kernels that have not yet applied the listed fixes.

How an attack unfolds

An attacker with local access triggers concurrent writes to the n_vclocks sysfs attribute while a PTP clock unregister path executes, causing the mutex to be acquired twice on the same CPU and producing a deadlock; listed threat actors have not been observed exploiting this specific issue.

How to fix it

Upgrade linux-lts packages to the listed fixed versions (Alpaquita 23: 6.1.81-r0; stream: 6.6.58-r0 or 6.12.41-r0) or apply the upstream commit 5d217e7031a5c06d366580fc6ddbf43527b780d4 and rebuild; disable PTP virtual clocks if patching is delayed.

How to confirm the fix worked

Verify the running kernel contains commit 5d217e7031a5c06d366580fc6ddbf43527b780d4 or matches the fixed package versions; confirm absence of the recursive locking warning in dmesg when exercising PTP sysfs paths.

Typical attack path

1. Obtain local access to a system running an affected kernel
2. Interact with PTP sysfs entries to store n_vclocks values
3. Trigger concurrent ptp_clock_unregister operations
4. Acquire n_vclocks_mux from both paths causing recursive lock
5. Induce kernel deadlock or warning

How to detect it

Search kernel logs and dmesg for the exact recursive locking warning mentioning n_vclocks_mux, ptp_vclock_in_use, and n_vclocks_store; correlate with processes writing to PTP sysfs entries around the time of the warning.

• WARNING: possible recursive locking detected
• ptp->n_vclocks_mux
• ptp_vclock_in_use drivers/ptp/ptp_private.h:103
• n_vclocks_store+0xf1/0x6d0 drivers/ptp/ptp_sysfs.c:215
• ptp_clock_unregister+0x21/0x250 drivers/ptp/ptp_clock.c:415

What your security team should do

• Prioritize kernel upgrades on all systems exposing PTP interfaces
• Monitor for the listed fixed versions in package repositories
• Temporarily restrict unprivileged access to PTP sysfs attributes until patched
• Include the deadlock warning pattern in kernel log monitoring rules