CVE-2025-38305

Severity CVSS v4.0:
Pending analysis
Type:
Unavailable / Other
Publication date:
10/07/2025
Last modified:
10/07/2025

Description

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ptp: remove ptp-&gt;n_vclocks check logic in ptp_vclock_in_use()<br /> <br /> There is no disagreement that we should check both ptp-&gt;is_virtual_clock<br /> and ptp-&gt;n_vclocks to check if the ptp virtual clock is in use.<br /> <br /> However, when we acquire ptp-&gt;n_vclocks_mux to read ptp-&gt;n_vclocks in<br /> ptp_vclock_in_use(), we observe a recursive lock in the call trace<br /> starting from n_vclocks_store().<br /> <br /> ============================================<br /> WARNING: possible recursive locking detected<br /> 6.15.0-rc6 #1 Not tainted<br /> --------------------------------------------<br /> syz.0.1540/13807 is trying to acquire lock:<br /> ffff888035a24868 (&amp;ptp-&gt;n_vclocks_mux){+.+.}-{4:4}, at:<br /> ptp_vclock_in_use drivers/ptp/ptp_private.h:103 [inline]<br /> ffff888035a24868 (&amp;ptp-&gt;n_vclocks_mux){+.+.}-{4:4}, at:<br /> ptp_clock_unregister+0x21/0x250 drivers/ptp/ptp_clock.c:415<br /> <br /> but task is already holding lock:<br /> ffff888030704868 (&amp;ptp-&gt;n_vclocks_mux){+.+.}-{4:4}, at:<br /> n_vclocks_store+0xf1/0x6d0 drivers/ptp/ptp_sysfs.c:215<br /> <br /> other info that might help us debug this:<br /> Possible unsafe locking scenario:<br /> <br /> CPU0<br /> ----<br /> lock(&amp;ptp-&gt;n_vclocks_mux);<br /> lock(&amp;ptp-&gt;n_vclocks_mux);<br /> <br /> *** DEADLOCK ***<br /> ....<br /> ============================================<br /> <br /> The best way to solve this is to remove the logic that checks<br /> ptp-&gt;n_vclocks in ptp_vclock_in_use().<br /> <br /> The reason why this is appropriate is that any path that uses<br /> ptp-&gt;n_vclocks must unconditionally check if ptp-&gt;n_vclocks is greater<br /> than 0 before unregistering vclocks, and all functions are already<br /> written this way. And in the function that uses ptp-&gt;n_vclocks, we<br /> already get ptp-&gt;n_vclocks_mux before unregistering vclocks.<br /> <br /> Therefore, we need to remove the redundant check for ptp-&gt;n_vclocks in<br /> ptp_vclock_in_use() to prevent recursive locking.

Impact