{ "schemaVersion": 1, "attribution": [ { "source": "CISA Known Exploited Vulnerabilities", "url": "https://www.cisa.gov/known-exploited-vulnerabilities-catalog", "licence": "US government work" }, { "source": "GitHub Advisory Database", "url": "https://github.com/advisories", "licence": "CC BY 4.0" }, { "source": "Have I Been Pwned", "url": "https://haveibeenpwned.com/", "licence": "CC BY 4.0" }, { "source": "CVE Program (CVE records)", "url": "https://www.cve.org/Legal/TermsOfUse", "licence": "CVE Terms of Use", "notice": "Copyright © 1999-2026, The MITRE Corporation. CVE is a trademark and the CVE logo is a registered trademark of The MITRE Corporation.", "terms": "CVE Usage: MITRE hereby grants you a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute Common Vulnerabilities and Exposures (CVE™). Any copy you make for such purposes is authorized provided that you reproduce MITRE's copyright designation and this license in any such copy." }, { "source": "FIRST EPSS", "url": "https://www.first.org/epss/", "licence": "free to use; FIRST requests attribution" } ], "record": { "id": "CVE-2025-39915", "sourceURL": "https://www.cve.org/CVERecord?id=CVE-2025-39915", "idYear": 2025, "status": "PUBLISHED", "publishedAt": "2025-10-01T07:44:37.884Z", "updatedAt": "2026-05-11T21:38:52.462Z", "importedAt": "2026-10-24T01:57:34.152Z", "snapshot": { "id": "cve_2026-10-24_midnight_baseline", "at": "2026-10-24T00:00:00.000Z", "source": "https://github.com/CVEProject/cvelistV5/releases/tag/cve_2026-10-24_0100Z" }, "facts": { "title": "net: phy: transfer phy_config_inband() locking responsibility to phylink", "summary": "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---", "affected": [ { "vendor": "Linux", "product": "Linux", "defaultStatus": "unaffected", "versions": [ { "version": "5fd0f1a02e750e2db4038dee60edea669ce5aab1", "status": "affected", "versionType": "git", "lessThan": "052ac41c379c8b87629808be612a482b2d0ae283" }, { "version": "5fd0f1a02e750e2db4038dee60edea669ce5aab1", "status": "affected", "versionType": "git", "lessThan": "e2a10daba84968f6b5777d150985fd7d6abc9c84" } ] }, { "vendor": "Linux", "product": "Linux", "defaultStatus": "affected", "versions": [ { "version": "6.14", "status": "affected" }, { "version": "0", "status": "unaffected", "versionType": "semver", "lessThan": "6.14" }, { "version": "6.16.8", "status": "unaffected", "versionType": "semver", "lessThanOrEqual": "6.16.*" }, { "version": "6.17", "status": "unaffected", "versionType": "original_commit_for_fix", "lessThanOrEqual": "*" } ] } ] } } }