CVE-2025-39915
Unknown Unknown - Not Provided
BaseFortify

Publication date: 2025-10-01

Last updated on: 2025-12-12

Assigner: kernel.org

Description
In the Linux kernel, the following vulnerability has been resolved: net: phy: transfer phy_config_inband() locking responsibility to phylink Problem description =================== Lockdep reports a possible circular locking dependency (AB/BA) between &pl->state_mutex and &phy->lock, as follows. phylink_resolve() // acquires &pl->state_mutex -> phylink_major_config() -> phy_config_inband() // acquires &pl->phydev->lock whereas all the other call sites where &pl->state_mutex and &pl->phydev->lock have the locking scheme reversed. Everywhere else, &pl->phydev->lock is acquired at the top level, and &pl->state_mutex at the lower level. A clear example is phylink_bringup_phy(). The outlier is the newly introduced phy_config_inband() and the existing lock order is the correct one. To understand why it cannot be the other way around, it is sufficient to consider phylink_phy_change(), phylink's callback from the PHY device's phy->phy_link_change() virtual method, invoked by the PHY state machine. phy_link_up() and phy_link_down(), the (indirect) callers of phylink_phy_change(), are called with &phydev->lock acquired. Then phylink_phy_change() acquires its own &pl->state_mutex, to serialize changes made to its pl->phy_state and pl->link_config. So all other instances of &pl->state_mutex and &phydev->lock must be consistent with this order. Problem impact ============== I think the kernel runs a serious deadlock risk if an existing phylink_resolve() thread, which results in a phy_config_inband() call, is concurrent with a phy_link_up() or phy_link_down() call, which will deadlock on &pl->state_mutex in phylink_phy_change(). Practically speaking, the impact may be limited by the slow speed of the medium auto-negotiation protocol, which makes it unlikely for the current state to still be unresolved when a new one is detected, but I think the problem is there. Nonetheless, the problem was discovered using lockdep. Proposed solution ================= Practically speaking, the phy_config_inband() requirement of having phydev->lock acquired must transfer to the caller (phylink is the only caller). There, it must bubble up until immediately before &pl->state_mutex is acquired, for the cases where that takes place. Solution details, considerations, notes ======================================= This is the phy_config_inband() call graph: sfp_upstream_ops :: connect_phy() | v phylink_sfp_connect_phy() | v phylink_sfp_config_phy() | | sfp_upstream_ops :: module_insert() | | | v | phylink_sfp_module_insert() | | | | sfp_upstream_ops :: module_start() | | | | | v | | phylink_sfp_module_start() | | | | v v | phylink_sfp_config_optical() phylink_start() | | | phylink_resume() v v | | phylink_sfp_set_config() | | | v v v phylink_mac_initial_config() | phylink_resolve() | | phylink_ethtool_ksettings_set() v v v phylink_major_config() | v phy_config_inband() phylink_major_config() caller #1, phylink_mac_initial_config(), does not acquire &pl->state_mutex nor do its callers. It must acquire &pl->phydev->lock prior to calling phylink_major_config(). phylink_major_config() caller #2, phylink_resolve() acquires &pl->state_mutex, thus also needs to acquire &pl->phydev->lock. phylink_major_config() caller #3, phylink_ethtool_ksettings_set(), is completely uninteresting, because it only call ---truncated---
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2025-10-01
Last Modified
2025-12-12
Generated
2026-05-07
AI Q&A
2025-10-01
EPSS Evaluated
2026-05-05
NVD
CVE-2025-39915
Affected Vendors & Products
Showing 6 associated CPEs
Vendor Product Version / Range
linux linux_kernel From 6.14 (inc) to 6.16.8 (exc)
linux linux_kernel 6.17
linux linux_kernel 6.17
linux linux_kernel 6.17
linux linux_kernel 6.17
linux linux_kernel 6.17
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-667 The product does not properly acquire or release a lock on a resource, leading to unexpected resource state changes and behaviors.
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability is a potential deadlock issue in the Linux kernel's network PHY (physical layer) code. It arises from a circular locking dependency between two mutexes: pl->state_mutex and phy->lock. Specifically, different parts of the code acquire these locks in inconsistent orders, which can cause a deadlock if certain functions run concurrently. The problem was detected by the kernel's lock dependency checker (lockdep). The fix involves transferring the locking responsibility for phy_config_inband() to ensure locks are acquired in a consistent order, preventing deadlocks.


How can this vulnerability impact me? :

This vulnerability can cause the Linux kernel to deadlock during network PHY configuration operations. A deadlock means that the system could hang or freeze in the affected code path, potentially causing network functionality to become unresponsive or degraded. However, the practical impact may be limited due to the slow speed of the medium auto-negotiation protocol, which reduces the likelihood of concurrent conflicting lock acquisitions. Still, the risk of serious deadlock exists if certain threads run concurrently.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart