{
  "cveId": "CVE-2025-39915",
  "url": "https://patchblox.com/security/cve/CVE-2025-39915",
  "summary": "CVE-2025-39915 is fixed in linux on 1 platform by DEBIAN-CVE-2025-39915 (version 6.16.8-1), released October 1, 2025. It is not reported as exploited. Patch Radar priority: Routine.",
  "title": "linux: In the Linux kernel, the following vulnerability has been resolved:  net: phy: transfer phy_config_inband() locking r...",
  "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 \u0026pl-\u003Estate_mutex and \u0026phy-\u003Elock, as follows.  phylink_resolve() // acquires \u0026pl-\u003Estate_mutex -\u003E phylink_major_config()    -\u003E phy_config_inband() // acquires \u0026pl-\u003Ephydev-\u003Elock  whereas all the other call sites where \u0026pl-\u003Estate_mutex and \u0026pl-\u003Ephydev-\u003Elock have the locking scheme reversed. Everywhere else, \u0026pl-\u003Ephydev-\u003Elock is acquired at the top level, and \u0026pl-\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\u0027s callback from the PHY device\u0027s 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 \u0026phydev-\u003Elock acquired. Then phylink_phy_change() acquires its own \u0026pl-\u003Estate_mutex, to serialize changes made to its pl-\u003Ephy_state and pl-\u003Elink_config. So all other instances of \u0026pl-\u003Estate_mutex and \u0026phydev-\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 \u0026pl-\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 \u0026pl-\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 \u0026pl-\u003Estate_mutex nor do its callers. It must acquire \u0026pl-\u003Ephydev-\u003Elock prior to calling phylink_major_config().  phylink_major_config() caller #2, phylink_resolve() acquires \u0026pl-\u003Estate_mutex, thus also needs to acquire \u0026pl-\u003Ephydev-\u003Elock.  phylink_major_config() caller #3, phylink_ethtool_ksettings_set(), is completely uninteresting, because it only call ---truncated---",
  "published": "2025-10-01T08:15:34Z",
  "severity": "medium",
  "cvss": 5.5,
  "cvssVector": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
  "epss": 0.00102,
  "epssPercentile": 0.00938,
  "priority": "Routine",
  "priorityTier": 4,
  "exploited": false,
  "vendorExploited": false,
  "disclosed": false,
  "fixes": [
    {
      "platform": "linux",
      "product": "linux",
      "release": "Debian 14",
      "fixedVersion": "6.16.8-1",
      "fix": "DEBIAN-CVE-2025-39915",
      "url": "https://patchblox.com/security/fix/linux/debian-cve-2025-39915",
      "released": "2025-10-01T08:15:34Z"
    }
  ],
  "noFixYet": [],
  "dataAsOf": "2026-11-09T13:31:49Z",
  "attribution": {
    "text": "Data: Patchblox Patch Radar",
    "url": "https://patchblox.com/security/patch-radar",
    "terms": "https://patchblox.com/security/patch-radar/use-the-data"
  }
}