Metrics
Affected Vendors & Products
Fri, 19 Dec 2025 18:00:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| First Time appeared |
Debian
Debian debian Linux |
|
| Weaknesses | NVD-CWE-noinfo | |
| CPEs | cpe:2.3:o:debian:debian_linux:11.0:*:*:*:*:*:*:* cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* cpe:2.3:o:linux:linux_kernel:5.14:-:*:*:*:*:*:* cpe:2.3:o:linux:linux_kernel:5.14:rc2:*:*:*:*:*:* cpe:2.3:o:linux:linux_kernel:5.14:rc3:*:*:*:*:*:* cpe:2.3:o:linux:linux_kernel:5.14:rc4:*:*:*:*:*:* cpe:2.3:o:linux:linux_kernel:5.14:rc5:*:*:*:*:*:* cpe:2.3:o:linux:linux_kernel:5.14:rc6:*:*:*:*:*:* cpe:2.3:o:linux:linux_kernel:5.14:rc7:*:*:*:*:*:* cpe:2.3:o:linux:linux_kernel:6.16:rc1:*:*:*:*:*:* |
|
| Vendors & Products |
Debian
Debian debian Linux |
|
| Metrics |
cvssV3_1
|
cvssV3_1
|
Mon, 03 Nov 2025 18:30:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| References |
|
Wed, 16 Jul 2025 13:45:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Metrics |
epss
|
epss
|
Sat, 12 Jul 2025 00:15:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| References |
| |
| Metrics |
threat_severity
|
cvssV3_1
|
Thu, 10 Jul 2025 08:00:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| 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. | |
| Title | ptp: remove ptp->n_vclocks check logic in ptp_vclock_in_use() | |
| References |
|
|
Status: PUBLISHED
Assigner: Linux
Published:
Updated: 2025-11-03T17:36:22.602Z
Reserved: 2025-04-16T04:51:24.002Z
Link: CVE-2025-38305
No data.
Status : Analyzed
Published: 2025-07-10T08:15:29.320
Modified: 2025-12-19T17:58:01.803
Link: CVE-2025-38305
OpenCVE Enrichment
Updated: 2025-07-13T11:06:33Z