[<prev] [next>] [day] [month] [year] [list]
Message-ID: <2025071014-CVE-2025-38305-4ad3@gregkh>
Date: Thu, 10 Jul 2025 09:42:46 +0200
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: linux-cve-announce@...r.kernel.org
Cc: Greg Kroah-Hartman <gregkh@...nel.org>
Subject: CVE-2025-38305: ptp: remove ptp->n_vclocks check logic in ptp_vclock_in_use()
From: Greg Kroah-Hartman <gregkh@...nel.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.
The Linux kernel CVE team has assigned CVE-2025-38305 to this issue.
Affected and fixed versions
===========================
Issue introduced in 5.14 with commit 73f37068d540eba5f93ba3a0019bf479d35ebd76 and fixed in 5.15.186 with commit 5d217e7031a5c06d366580fc6ddbf43527b780d4
Issue introduced in 5.14 with commit 73f37068d540eba5f93ba3a0019bf479d35ebd76 and fixed in 6.1.142 with commit b1b73c452331451020be3bf4b014901015ae6663
Issue introduced in 5.14 with commit 73f37068d540eba5f93ba3a0019bf479d35ebd76 and fixed in 6.6.94 with commit 259119595227fd20f6aa29d85abe086b6fdd9eb1
Issue introduced in 5.14 with commit 73f37068d540eba5f93ba3a0019bf479d35ebd76 and fixed in 6.12.34 with commit b93e6fef4eda48e17d9c642b9abad98a066fd4a3
Issue introduced in 5.14 with commit 73f37068d540eba5f93ba3a0019bf479d35ebd76 and fixed in 6.15.3 with commit ef8fc007c28a30a4c0d90bf755e0f343d99bb392
Issue introduced in 5.14 with commit 73f37068d540eba5f93ba3a0019bf479d35ebd76 and fixed in 6.16-rc2 with commit 87f7ce260a3c838b49e1dc1ceedf1006795157a2
Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.
Unaffected versions might change over time as fixes are backported to
older supported kernel versions. The official CVE entry at
https://cve.org/CVERecord/?id=CVE-2025-38305
will be updated if fixes are backported, please check that for the most
up to date information about this issue.
Affected files
==============
The file(s) affected by this issue are:
drivers/ptp/ptp_private.h
Mitigation
==========
The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes. Individual
changes are never tested alone, but rather are part of a larger kernel
release. Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all. If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
https://git.kernel.org/stable/c/5d217e7031a5c06d366580fc6ddbf43527b780d4
https://git.kernel.org/stable/c/b1b73c452331451020be3bf4b014901015ae6663
https://git.kernel.org/stable/c/259119595227fd20f6aa29d85abe086b6fdd9eb1
https://git.kernel.org/stable/c/b93e6fef4eda48e17d9c642b9abad98a066fd4a3
https://git.kernel.org/stable/c/ef8fc007c28a30a4c0d90bf755e0f343d99bb392
https://git.kernel.org/stable/c/87f7ce260a3c838b49e1dc1ceedf1006795157a2
Powered by blists - more mailing lists