CVE - CVE-2025-38305

CVE-ID
CVE-2025-38305	Learn more at National Vulnerability Database (NVD) • CVSS Severity Rating • Fix Information • Vulnerable Software Versions • SCAP Mappings • CPE Information
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.
References
Note: References are provided for the convenience of the reader to help distinguish between vulnerabilities. The list is not intended to be complete.
MISC:https://git.kernel.org/stable/c/259119595227fd20f6aa29d85abe086b6fdd9eb1 URL:https://git.kernel.org/stable/c/259119595227fd20f6aa29d85abe086b6fdd9eb1 MISC:https://git.kernel.org/stable/c/5d217e7031a5c06d366580fc6ddbf43527b780d4 URL:https://git.kernel.org/stable/c/5d217e7031a5c06d366580fc6ddbf43527b780d4 MISC:https://git.kernel.org/stable/c/87f7ce260a3c838b49e1dc1ceedf1006795157a2 URL:https://git.kernel.org/stable/c/87f7ce260a3c838b49e1dc1ceedf1006795157a2 MISC:https://git.kernel.org/stable/c/b1b73c452331451020be3bf4b014901015ae6663 URL:https://git.kernel.org/stable/c/b1b73c452331451020be3bf4b014901015ae6663 MISC:https://git.kernel.org/stable/c/b93e6fef4eda48e17d9c642b9abad98a066fd4a3 URL:https://git.kernel.org/stable/c/b93e6fef4eda48e17d9c642b9abad98a066fd4a3 MISC:https://git.kernel.org/stable/c/ef8fc007c28a30a4c0d90bf755e0f343d99bb392 URL:https://git.kernel.org/stable/c/ef8fc007c28a30a4c0d90bf755e0f343d99bb392
Assigning CNA
kernel.org
Date Record Created
20250416	Disclaimer: The record creation date may reflect when the CVE ID was allocated or reserved, and does not necessarily indicate when this vulnerability was discovered, shared with the affected vendor, publicly disclosed, or updated in CVE.
Phase (Legacy)
Assigned (20250416)
Votes (Legacy)

Comments (Legacy)

Proposed (Legacy)
N/A
This is an record on the CVE List, which provides common identifiers for publicly known cybersecurity vulnerabilities.
Search CVE Using Keywords: You can also search by reference using the CVE Reference Maps.
For More Information: CVE Request Web Form (select "Other" from dropdown)