CVE-2025-39905

Advisory lineage Upstream: 0 Downstream: 3
Modified
Published: 01 Oct 2025, 07:44
Last modified:11 May 2026, 21:38

Vulnerability Summary

Overall Risk (default)
medium
28/100
CVSS Score
7 HIGH
v3.1 (cve.org)
EPSS Score
0.01% LOW
0% probability 0.00%
KEV
Not listed
Ransomware
No reports
Public exploits
None found
Dark Web
Not detected

Timeline

01 Oct 2025, 07:44
Published
Vulnerability first disclosed
11 May 2026, 21:38
Last Modified
Vulnerability information updated

Description

In the Linux kernel, the following vulnerability has been resolved: net: phylink: add lock for serializing concurrent pl->phydev writes with resolver Currently phylink_resolve() protects itself against concurrent phylink_bringup_phy() or phylink_disconnect_phy() calls which modify pl->phydev by relying on pl->state_mutex. The problem is that in phylink_resolve(), pl->state_mutex is in a lock inversion state with pl->phydev->lock. So pl->phydev->lock needs to be acquired prior to pl->state_mutex. But that requires dereferencing pl->phydev in the first place, and without pl->state_mutex, that is racy. Hence the reason for the extra lock. Currently it is redundant, but it will serve a functional purpose once mutex_lock(&phy->lock) will be moved outside of the mutex_lock(&pl->state_mutex) section. Another alternative considered would have been to let phylink_resolve() acquire the rtnl_mutex, which is also held when phylink_bringup_phy() and phylink_disconnect_phy() are called. But since phylink_disconnect_phy() runs under rtnl_lock(), it would deadlock with phylink_resolve() when calling flush_work(&pl->resolve). Additionally, it would have been undesirable because it would have unnecessarily blocked many other call paths as well in the entire kernel, so the smaller-scoped lock was preferred.

CVSS Metrics

  • v3.1•HIGH•Score: 7CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H

EPSS Trends

Current EPSS score: 0.01%• Percentile: 1%

Techniques & Countermeasures

  • CWE-362•Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')

    The product contains a concurrent code sequence that requires temporary, exclusive access to a shared resource, but a timing window exists in which the shared resource can be modified by another code sequence operating concurrently.

Affected Systems

  • linux•linux

    ≥ 5fd0f1a02e750e2db4038dee60edea669ce5aab1, < 56fe63b05ec84ae6674269d78397cec43a7a295a | ≥ 5fd0f1a02e750e2db4038dee60edea669ce5aab1, < 0ba5b2f2c381dbec9ed9e4ab3ae5d3e667de0dc3 | 6.14

  • linux•linux_kernel

    < 6.16.8 | 6.17:rc1 | 6.17:rc2 | 6.17:rc3 | 6.17:rc4 | 6.17:rc5

References (2)