CVE-2025-39915 (GCVE-0-2025-39915)
Vulnerability from cvelistv5
Published
2025-10-01 07:44
Modified
2025-10-01 07:44
Severity ?
VLAI Severity ?
EPSS score ?
Summary
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---
References
Impacted products
{
"containers": {
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"drivers/net/phy/phy.c",
"drivers/net/phy/phylink.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "052ac41c379c8b87629808be612a482b2d0ae283",
"status": "affected",
"version": "5fd0f1a02e750e2db4038dee60edea669ce5aab1",
"versionType": "git"
},
{
"lessThan": "e2a10daba84968f6b5777d150985fd7d6abc9c84",
"status": "affected",
"version": "5fd0f1a02e750e2db4038dee60edea669ce5aab1",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"drivers/net/phy/phy.c",
"drivers/net/phy/phylink.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "6.14"
},
{
"lessThan": "6.14",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.16.*",
"status": "unaffected",
"version": "6.16.8",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.17",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.16.8",
"versionStartIncluding": "6.14",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.17",
"versionStartIncluding": "6.14",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"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\u0026pl-\u003estate_mutex and \u0026phy-\u003elock, as follows.\n\nphylink_resolve() // acquires \u0026pl-\u003estate_mutex\n-\u003e phylink_major_config()\n -\u003e phy_config_inband() // acquires \u0026pl-\u003ephydev-\u003elock\n\nwhereas all the other call sites where \u0026pl-\u003estate_mutex and\n\u0026pl-\u003ephydev-\u003elock have the locking scheme reversed. Everywhere else,\n\u0026pl-\u003ephydev-\u003elock is acquired at the top level, and \u0026pl-\u003estate_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\u0027s\ncallback from the PHY device\u0027s phy-\u003ephy_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 \u0026phydev-\u003elock acquired.\nThen phylink_phy_change() acquires its own \u0026pl-\u003estate_mutex, to\nserialize changes made to its pl-\u003ephy_state and pl-\u003elink_config.\nSo all other instances of \u0026pl-\u003estate_mutex and \u0026phydev-\u003elock 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 \u0026pl-\u003estate_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-\u003elock acquired must transfer to the caller (phylink is the only\ncaller). There, it must bubble up until immediately before\n\u0026pl-\u003estate_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 \u0026pl-\u003estate_mutex nor do its callers. It must acquire\n\u0026pl-\u003ephydev-\u003elock prior to calling phylink_major_config().\n\nphylink_major_config() caller #2, phylink_resolve() acquires\n\u0026pl-\u003estate_mutex, thus also needs to acquire \u0026pl-\u003ephydev-\u003elock.\n\nphylink_major_config() caller #3, phylink_ethtool_ksettings_set(), is\ncompletely uninteresting, because it only call\n---truncated---"
}
],
"providerMetadata": {
"dateUpdated": "2025-10-01T07:44:37.884Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/052ac41c379c8b87629808be612a482b2d0ae283"
},
{
"url": "https://git.kernel.org/stable/c/e2a10daba84968f6b5777d150985fd7d6abc9c84"
}
],
"title": "net: phy: transfer phy_config_inband() locking responsibility to phylink",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2025-39915",
"datePublished": "2025-10-01T07:44:37.884Z",
"dateReserved": "2025-04-16T07:20:57.147Z",
"dateUpdated": "2025-10-01T07:44:37.884Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.1",
"vulnerability-lookup:meta": {
"nvd": "{\"cve\":{\"id\":\"CVE-2025-39915\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2025-10-01T08:15:34.647\",\"lastModified\":\"2025-10-02T19:12:17.160\",\"vulnStatus\":\"Awaiting Analysis\",\"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\u0026pl-\u003estate_mutex and \u0026phy-\u003elock, as follows.\\n\\nphylink_resolve() // acquires \u0026pl-\u003estate_mutex\\n-\u003e phylink_major_config()\\n -\u003e phy_config_inband() // acquires \u0026pl-\u003ephydev-\u003elock\\n\\nwhereas all the other call sites where \u0026pl-\u003estate_mutex and\\n\u0026pl-\u003ephydev-\u003elock have the locking scheme reversed. Everywhere else,\\n\u0026pl-\u003ephydev-\u003elock is acquired at the top level, and \u0026pl-\u003estate_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\u0027s\\ncallback from the PHY device\u0027s phy-\u003ephy_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 \u0026phydev-\u003elock acquired.\\nThen phylink_phy_change() acquires its own \u0026pl-\u003estate_mutex, to\\nserialize changes made to its pl-\u003ephy_state and pl-\u003elink_config.\\nSo all other instances of \u0026pl-\u003estate_mutex and \u0026phydev-\u003elock 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 \u0026pl-\u003estate_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-\u003elock acquired must transfer to the caller (phylink is the only\\ncaller). There, it must bubble up until immediately before\\n\u0026pl-\u003estate_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 \u0026pl-\u003estate_mutex nor do its callers. It must acquire\\n\u0026pl-\u003ephydev-\u003elock prior to calling phylink_major_config().\\n\\nphylink_major_config() caller #2, phylink_resolve() acquires\\n\u0026pl-\u003estate_mutex, thus also needs to acquire \u0026pl-\u003ephydev-\u003elock.\\n\\nphylink_major_config() caller #3, phylink_ethtool_ksettings_set(), is\\ncompletely uninteresting, because it only call\\n---truncated---\"}],\"metrics\":{},\"references\":[{\"url\":\"https://git.kernel.org/stable/c/052ac41c379c8b87629808be612a482b2d0ae283\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/e2a10daba84968f6b5777d150985fd7d6abc9c84\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"}]}}"
}
}
Loading…
Loading…
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
- Confirmed: The vulnerability is confirmed from an analyst perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
- Patched: This vulnerability was successfully patched by the user reporting the sighting.
- Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
- Not confirmed: The user expresses doubt about the veracity of the vulnerability.
- Not patched: This vulnerability was not successfully patched by the user reporting the sighting.
Loading…
Loading…