{"resultsPerPage":1,"startIndex":0,"totalResults":1,"format":"NVD_CVE","version":"2.0","timestamp":"2026-05-11T14:08:06.069","vulnerabilities":[{"cve":{"id":"CVE-2025-39915","sourceIdentifier":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","published":"2025-10-01T08:15:34.647","lastModified":"2026-01-14T18:16:39.857","vulnStatus":"Modified","cveTags":[],"descriptions":[{"lang":"en","value":"In the Linux kernel, the following vulnerability has been resolved:\n\nnet: phy: transfer phy_config_inband() locking responsibility to phylink\n\nProblem description\n===================\n\nLockdep reports a possible circular locking dependency (AB/BA) between\n&pl->state_mutex and &phy->lock, as follows.\n\nphylink_resolve() // acquires &pl->state_mutex\n-> phylink_major_config()\n   -> phy_config_inband() // acquires &pl->phydev->lock\n\nwhereas all the other call sites where &pl->state_mutex and\n&pl->phydev->lock have the locking scheme reversed. Everywhere else,\n&pl->phydev->lock is acquired at the top level, and &pl->state_mutex at\nthe lower level. A clear example is phylink_bringup_phy().\n\nThe outlier is the newly introduced phy_config_inband() and the existing\nlock order is the correct one. To understand why it cannot be the other\nway around, it is sufficient to consider phylink_phy_change(), phylink's\ncallback from the PHY device's phy->phy_link_change() virtual method,\ninvoked by the PHY state machine.\n\nphy_link_up() and phy_link_down(), the (indirect) callers of\nphylink_phy_change(), are called with &phydev->lock acquired.\nThen phylink_phy_change() acquires its own &pl->state_mutex, to\nserialize changes made to its pl->phy_state and pl->link_config.\nSo all other instances of &pl->state_mutex and &phydev->lock must be\nconsistent with this order.\n\nProblem impact\n==============\n\nI think the kernel runs a serious deadlock risk if an existing\nphylink_resolve() thread, which results in a phy_config_inband() call,\nis concurrent with a phy_link_up() or phy_link_down() call, which will\ndeadlock on &pl->state_mutex in phylink_phy_change(). Practically\nspeaking, the impact may be limited by the slow speed of the medium\nauto-negotiation protocol, which makes it unlikely for the current state\nto still be unresolved when a new one is detected, but I think the\nproblem is there. Nonetheless, the problem was discovered using lockdep.\n\nProposed solution\n=================\n\nPractically speaking, the phy_config_inband() requirement of having\nphydev->lock acquired must transfer to the caller (phylink is the only\ncaller). There, it must bubble up until immediately before\n&pl->state_mutex is acquired, for the cases where that takes place.\n\nSolution details, considerations, notes\n=======================================\n\nThis is the phy_config_inband() call graph:\n\n                          sfp_upstream_ops :: connect_phy()\n                          |\n                          v\n                          phylink_sfp_connect_phy()\n                          |\n                          v\n                          phylink_sfp_config_phy()\n                          |\n                          |   sfp_upstream_ops :: module_insert()\n                          |   |\n                          |   v\n                          |   phylink_sfp_module_insert()\n                          |   |\n                          |   |   sfp_upstream_ops :: module_start()\n                          |   |   |\n                          |   |   v\n                          |   |   phylink_sfp_module_start()\n                          |   |   |\n                          |   v   v\n                          |   phylink_sfp_config_optical()\n phylink_start()          |   |\n   |   phylink_resume()   v   v\n   |   |  phylink_sfp_set_config()\n   |   |  |\n   v   v  v\n phylink_mac_initial_config()\n   |   phylink_resolve()\n   |   |  phylink_ethtool_ksettings_set()\n   v   v  v\n   phylink_major_config()\n            |\n            v\n    phy_config_inband()\n\nphylink_major_config() caller #1, phylink_mac_initial_config(), does not\nacquire &pl->state_mutex nor do its callers. It must acquire\n&pl->phydev->lock prior to calling phylink_major_config().\n\nphylink_major_config() caller #2, phylink_resolve() acquires\n&pl->state_mutex, thus also needs to acquire &pl->phydev->lock.\n\nphylink_major_config() caller #3, phylink_ethtool_ksettings_set(), is\ncompletely uninteresting, because it only call\n---truncated---"}],"metrics":{"cvssMetricV31":[{"source":"nvd@nist.gov","type":"Primary","cvssData":{"version":"3.1","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H","baseScore":5.5,"baseSeverity":"MEDIUM","attackVector":"LOCAL","attackComplexity":"LOW","privilegesRequired":"LOW","userInteraction":"NONE","scope":"UNCHANGED","confidentialityImpact":"NONE","integrityImpact":"NONE","availabilityImpact":"HIGH"},"exploitabilityScore":1.8,"impactScore":3.6},{"source":"134c704f-9b21-4f2e-91b3-4a467353bcc0","type":"Secondary","cvssData":{"version":"3.1","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H","baseScore":5.5,"baseSeverity":"MEDIUM","attackVector":"LOCAL","attackComplexity":"LOW","privilegesRequired":"LOW","userInteraction":"NONE","scope":"UNCHANGED","confidentialityImpact":"NONE","integrityImpact":"NONE","availabilityImpact":"HIGH"},"exploitabilityScore":1.8,"impactScore":3.6}]},"weaknesses":[{"source":"nvd@nist.gov","type":"Primary","description":[{"lang":"en","value":"CWE-667"}]},{"source":"134c704f-9b21-4f2e-91b3-4a467353bcc0","type":"Secondary","description":[{"lang":"en","value":"CWE-667"}]}],"configurations":[{"nodes":[{"operator":"OR","negate":false,"cpeMatch":[{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"6.14","versionEndExcluding":"6.16.8","matchCriteriaId":"F6C3723D-6863-4401-AC08-FEB7AB987047"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:6.17:rc1:*:*:*:*:*:*","matchCriteriaId":"327D22EF-390B-454C-BD31-2ED23C998A1C"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:6.17:rc2:*:*:*:*:*:*","matchCriteriaId":"C730CD9A-D969-4A8E-9522-162AAF7C0EE9"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:6.17:rc3:*:*:*:*:*:*","matchCriteriaId":"39982C4B-716E-4B2F-8196-FA301F47807D"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:6.17:rc4:*:*:*:*:*:*","matchCriteriaId":"340BEEA9-D70D-4290-B502-FBB1032353B1"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:6.17:rc5:*:*:*:*:*:*","matchCriteriaId":"47E4C5C0-079F-4838-971B-8C503D48FCC2"}]}]}],"references":[{"url":"https://git.kernel.org/stable/c/052ac41c379c8b87629808be612a482b2d0ae283","source":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":["Patch"]},{"url":"https://git.kernel.org/stable/c/e2a10daba84968f6b5777d150985fd7d6abc9c84","source":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":["Patch"]}]}}]}