CVE-2025-38305
Unknown Unknown - Not Provided
BaseFortify

Publication date: 2025-07-10

Last updated on: 2025-11-03

Assigner: kernel.org

Description
In the Linux kernel, the following vulnerability has been resolved: ptp: remove ptp->n_vclocks check logic in ptp_vclock_in_use() There is no disagreement that we should check both ptp->is_virtual_clock and ptp->n_vclocks to check if the ptp virtual clock is in use. However, when we acquire ptp->n_vclocks_mux to read ptp->n_vclocks in ptp_vclock_in_use(), we observe a recursive lock in the call trace starting from n_vclocks_store(). ============================================ WARNING: possible recursive locking detected 6.15.0-rc6 #1 Not tainted -------------------------------------------- syz.0.1540/13807 is trying to acquire lock: ffff888035a24868 (&ptp->n_vclocks_mux){+.+.}-{4:4}, at: ptp_vclock_in_use drivers/ptp/ptp_private.h:103 [inline] ffff888035a24868 (&ptp->n_vclocks_mux){+.+.}-{4:4}, at: ptp_clock_unregister+0x21/0x250 drivers/ptp/ptp_clock.c:415 but task is already holding lock: ffff888030704868 (&ptp->n_vclocks_mux){+.+.}-{4:4}, at: n_vclocks_store+0xf1/0x6d0 drivers/ptp/ptp_sysfs.c:215 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&ptp->n_vclocks_mux); lock(&ptp->n_vclocks_mux); *** DEADLOCK *** .... ============================================ The best way to solve this is to remove the logic that checks ptp->n_vclocks in ptp_vclock_in_use(). The reason why this is appropriate is that any path that uses ptp->n_vclocks must unconditionally check if ptp->n_vclocks is greater than 0 before unregistering vclocks, and all functions are already written this way. And in the function that uses ptp->n_vclocks, we already get ptp->n_vclocks_mux before unregistering vclocks. Therefore, we need to remove the redundant check for ptp->n_vclocks in ptp_vclock_in_use() to prevent recursive locking.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2025-07-10
Last Modified
2025-11-03
Generated
2026-05-07
AI Q&A
2025-07-10
EPSS Evaluated
2026-05-05
NVD
CVE-2025-38305
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
linux linux_kernel *
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability involves a recursive locking issue in the Linux kernel's Precision Time Protocol (PTP) subsystem. Specifically, the function ptp_vclock_in_use() checks the ptp->n_vclocks variable while holding a lock (ptp->n_vclocks_mux), but this leads to a recursive lock acquisition and potential deadlock. The fix removes the redundant check of ptp->n_vclocks in ptp_vclock_in_use() because other parts of the code already handle this check safely with proper locking, preventing the recursive locking scenario.


How can this vulnerability impact me? :

This vulnerability can cause a deadlock in the Linux kernel's PTP subsystem, potentially leading to system hangs or crashes when the affected code path is executed. This can impact system stability and reliability, especially in environments relying on precise time synchronization.


What immediate steps should I take to mitigate this vulnerability?

The vulnerability is caused by recursive locking due to redundant checks of ptp->n_vclocks in ptp_vclock_in_use(). The immediate mitigation is to update the Linux kernel to a version where this logic has been removed, as the fix involves removing the redundant check for ptp->n_vclocks in ptp_vclock_in_use() to prevent recursive locking. Ensuring that your kernel is patched with this fix will mitigate the issue.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart