CVE-2025-39915
Full vulnerability record from the local CVENow database.
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---
View original CVE JSON
{
"id": "CVE-2025-39915",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2025-10-01T08:15:34.647",
"lastModified": "2026-10-19T21:10:00.160",
"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---"
},
{
"lang": "es",
"value": "En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:\n\nnet: phy: transferir la responsabilidad de bloqueo de phy_config_inband() a phylink\n\nDescripción del problema\n===================\n\nLockdep informa una posible dependencia de bloqueo circular (AB/BA) entre\n&pl->state_mutex y &phy->lock, como sigue.\n\nphylink_resolve() // adquiere &pl->state_mutex\n-> phylink_major_config()\n -> phy_config_inband() // adquiere &pl->phydev->lock\n\nmientras que todos los demás sitios de llamada donde &pl->state_mutex y\n&pl->phydev->lock tienen el esquema de bloqueo invertido. En todas partes,\n&pl->phydev->lock se adquiere en el nivel superior, y &pl->state_mutex en\nel nivel inferior. Un ejemplo claro es phylink_bringup_phy().\n\nEl caso atípico es el recién introducido phy_config_inband() y el orden\nde bloqueo existente es el correcto. Para entender por qué no puede ser al\nrevés, es suficiente considerar phylink_phy_change(), la devolución de\nllamada de phylink del método virtual phy->phy_link_change() del\ndispositivo PHY, invocado por la máquina de estados PHY.\n\nphy_link_up() y phy_link_down(), los llamadores (indirectos) de\nphylink_phy_change(), se llaman con &phydev->lock adquirido.\nLuego phylink_phy_change() adquiere su propio &pl->state_mutex, para\nserializar los cambios realizados en su pl->phy_state y pl->link_config.\nAsí que todas las demás instancias de &pl->state_mutex y &phydev->lock\ndeben ser consistentes con este orden.\n\nImpacto del problema\n==============\n\nCreo que el kernel corre un grave riesgo de interbloqueo si un hilo\nexistente de phylink_resolve(), que resulta en una llamada a\nphy_config_inband(), es concurrente con una llamada a phy_link_up() o\nphy_link_down(), lo que provocará un interbloqueo en &pl->state_mutex en\nphylink_phy_change(). Prácticamente hablando, el impacto puede estar\nlimitado por la lenta velocidad del protocolo de auto-negociación del\nmedio, lo que hace improbable que el estado actual siga sin resolverse\ncuando se detecta uno nuevo, pero creo que el problema existe. No\nobstante, el problema fue descubierto usando lockdep.\n\nSolución propuesta\n=================\n\nPrácticamente hablando, el requisito de phy_config_inband() de tener\nphydev->lock adquirido debe transferirse al llamador (phylink es el único\nllamador). Allí, debe ascender hasta inmediatamente antes de que se\nadquiera &pl->state_mutex, para los casos en que eso ocurra.\n\nDetalles de la solución, consideraciones, notas\n=======================================\n\nEste es el grafo de llamadas de phy_config_inband():\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\nEl llamador #1 de phylink_major_config(), phylink_mac_initial_config(),\nno adquiere &pl->state_mutex ni lo hacen sus llamadores. Debe adquirir\n&pl->phydev->lock antes de llamar a phylink_major_config().\n\nEl llamador #2 de --TRUNCADO--"
}
],
"affected": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"affectedData": [
{
"vendor": "Linux",
"product": "Linux",
"defaultStatus": "unaffected",
"programFiles": [
"drivers/net/phy/phy.c",
"drivers/net/phy/phylink.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"versions": [
{
"version": "5fd0f1a02e750e2db4038dee60edea669ce5aab1",
"lessThan": "052ac41c379c8b87629808be612a482b2d0ae283",
"versionType": "git",
"status": "affected"
},
{
"version": "5fd0f1a02e750e2db4038dee60edea669ce5aab1",
"lessThan": "e2a10daba84968f6b5777d150985fd7d6abc9c84",
"versionType": "git",
"status": "affected"
}
]
},
{
"vendor": "Linux",
"product": "Linux",
"defaultStatus": "affected",
"programFiles": [
"drivers/net/phy/phy.c",
"drivers/net/phy/phylink.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"versions": [
{
"version": "6.14",
"status": "affected"
},
{
"version": "0",
"lessThan": "6.14",
"versionType": "semver",
"status": "unaffected"
},
{
"version": "6.16.8",
"lessThanOrEqual": "6.16.*",
"versionType": "semver",
"status": "unaffected"
},
{
"version": "6.17",
"lessThanOrEqual": "*",
"versionType": "original_commit_for_fix",
"status": "unaffected"
}
]
}
]
}
],
"metrics": {
"cvssMetricV31": [
{
"source": "[email protected]",
"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
}
],
"ssvcV203": [
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"ssvcData": {
"timestamp": "2026-01-14T17:42:55.510925Z",
"id": "CVE-2025-39915",
"options": [
{
"exploitation": "none"
},
{
"automatable": "no"
},
{
"technicalImpact": "partial"
}
],
"role": "CISA Coordinator",
"version": "2.0.3"
}
}
]
},
"weaknesses": [
{
"source": "[email protected]",
"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"
]
}
]
}