{"id":"DEBIAN-CVE-2025-39915","details":"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-\u003estate_mutex and &phy-\u003elock, as follows.  phylink_resolve() // acquires &pl-\u003estate_mutex -\u003e phylink_major_config()    -\u003e phy_config_inband() // acquires &pl-\u003ephydev-\u003elock  whereas all the other call sites where &pl-\u003estate_mutex and &pl-\u003ephydev-\u003elock have the locking scheme reversed. Everywhere else, &pl-\u003ephydev-\u003elock is acquired at the top level, and &pl-\u003estate_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-\u003ephy_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-\u003elock acquired. Then phylink_phy_change() acquires its own &pl-\u003estate_mutex, to serialize changes made to its pl-\u003ephy_state and pl-\u003elink_config. So all other instances of &pl-\u003estate_mutex and &phydev-\u003elock 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-\u003estate_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-\u003elock acquired must transfer to the caller (phylink is the only caller). There, it must bubble up until immediately before &pl-\u003estate_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-\u003estate_mutex nor do its callers. It must acquire &pl-\u003ephydev-\u003elock prior to calling phylink_major_config().  phylink_major_config() caller #2, phylink_resolve() acquires &pl-\u003estate_mutex, thus also needs to acquire &pl-\u003ephydev-\u003elock.  phylink_major_config() caller #3, phylink_ethtool_ksettings_set(), is completely uninteresting, because it only call ---truncated---","modified":"2026-09-01T20:05:50.845214144Z","published":"2025-10-01T08:15:34.647Z","upstream":["CVE-2025-39915"],"references":[{"type":"ADVISORY","url":"https://security-tracker.debian.org/tracker/CVE-2025-39915"}],"affected":[{"package":{"name":"linux","ecosystem":"Debian:14","purl":"pkg:deb/debian/linux?arch=source&distro=forky"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.16.8-1"}]}],"versions":["6.12.100-1","6.12.101-1","6.12.105-1","6.12.107-1","6.12.38-1","6.12.41-1","6.12.43-1","6.12.43-1~bpo12+1","6.12.48-1","6.12.57-1","6.12.57-1~bpo12+1","6.12.63-1","6.12.63-1~bpo12+1","6.12.69-1","6.12.69-1~bpo12+1","6.12.73-1","6.12.73-1~bpo12+1","6.12.74-1","6.12.74-2","6.12.74-2~bpo12+1","6.12.85-1","6.12.85-1~bpo12+1","6.12.86-1","6.12.86-1~bpo12+1","6.12.88-1","6.12.88-1~bpo12+1","6.12.90-1","6.12.90-1~bpo12+1","6.12.90-2","6.12.90-2~bpo12+1","6.12.94-1","6.12.94-1~bpo12+1","6.12.95-1","6.12.95-1~bpo12+1","6.12.96-1","6.13.10-1~exp1","6.13.11-1~exp1","6.13.2-1~exp1","6.13.3-1~exp1","6.13.4-1~exp1","6.13.5-1~exp1","6.13.6-1~exp1","6.13.7-1~exp1","6.13.8-1~exp1","6.13.9-1~exp1","6.13~rc6-1~exp1","6.13~rc7-1~exp1","6.14.3-1~exp1","6.14.5-1~exp1","6.14.6-1~exp1","6.15-1~exp1","6.15.1-1~exp1","6.15.2-1~exp1","6.15.3-1~exp1","6.15.4-1~exp1","6.15.5-1~exp1","6.15.6-1~exp1","6.15~rc7-1~exp1","6.16-1~exp1","6.16.1-1~exp1","6.16.3-1","6.16.3-1~bpo13+1","6.16.5-1","6.16.6-1","6.16.7-1","6.16~rc7-1~exp1"],"ecosystem_specific":{"urgency":"not yet assigned"},"database_specific":{"source":"https://storage.googleapis.com/debian-osv/debian-cve-osv/DEBIAN-CVE-2025-39915.json"}}],"schema_version":"1.9.0","severity":[{"type":"CVSS_V3","score":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H"}]}