CVE-2025-39905 (GCVE-0-2025-39905)
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: phylink: add lock for serializing concurrent pl->phydev writes with resolver
Currently phylink_resolve() protects itself against concurrent
phylink_bringup_phy() or phylink_disconnect_phy() calls which modify
pl->phydev by relying on pl->state_mutex.
The problem is that in phylink_resolve(), pl->state_mutex is in a lock
inversion state with pl->phydev->lock. So pl->phydev->lock needs to be
acquired prior to pl->state_mutex. But that requires dereferencing
pl->phydev in the first place, and without pl->state_mutex, that is
racy.
Hence the reason for the extra lock. Currently it is redundant, but it
will serve a functional purpose once mutex_lock(&phy->lock) will be
moved outside of the mutex_lock(&pl->state_mutex) section.
Another alternative considered would have been to let phylink_resolve()
acquire the rtnl_mutex, which is also held when phylink_bringup_phy()
and phylink_disconnect_phy() are called. But since phylink_disconnect_phy()
runs under rtnl_lock(), it would deadlock with phylink_resolve() when
calling flush_work(&pl->resolve). Additionally, it would have been
undesirable because it would have unnecessarily blocked many other call
paths as well in the entire kernel, so the smaller-scoped lock was
preferred.
References
Impacted products
{
"containers": {
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"drivers/net/phy/phylink.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "56fe63b05ec84ae6674269d78397cec43a7a295a",
"status": "affected",
"version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
"versionType": "git"
},
{
"lessThan": "0ba5b2f2c381dbec9ed9e4ab3ae5d3e667de0dc3",
"status": "affected",
"version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"drivers/net/phy/phylink.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"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",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.17",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: phylink: add lock for serializing concurrent pl-\u003ephydev writes with resolver\n\nCurrently phylink_resolve() protects itself against concurrent\nphylink_bringup_phy() or phylink_disconnect_phy() calls which modify\npl-\u003ephydev by relying on pl-\u003estate_mutex.\n\nThe problem is that in phylink_resolve(), pl-\u003estate_mutex is in a lock\ninversion state with pl-\u003ephydev-\u003elock. So pl-\u003ephydev-\u003elock needs to be\nacquired prior to pl-\u003estate_mutex. But that requires dereferencing\npl-\u003ephydev in the first place, and without pl-\u003estate_mutex, that is\nracy.\n\nHence the reason for the extra lock. Currently it is redundant, but it\nwill serve a functional purpose once mutex_lock(\u0026phy-\u003elock) will be\nmoved outside of the mutex_lock(\u0026pl-\u003estate_mutex) section.\n\nAnother alternative considered would have been to let phylink_resolve()\nacquire the rtnl_mutex, which is also held when phylink_bringup_phy()\nand phylink_disconnect_phy() are called. But since phylink_disconnect_phy()\nruns under rtnl_lock(), it would deadlock with phylink_resolve() when\ncalling flush_work(\u0026pl-\u003eresolve). Additionally, it would have been\nundesirable because it would have unnecessarily blocked many other call\npaths as well in the entire kernel, so the smaller-scoped lock was\npreferred."
}
],
"providerMetadata": {
"dateUpdated": "2025-10-01T07:44:28.758Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/56fe63b05ec84ae6674269d78397cec43a7a295a"
},
{
"url": "https://git.kernel.org/stable/c/0ba5b2f2c381dbec9ed9e4ab3ae5d3e667de0dc3"
}
],
"title": "net: phylink: add lock for serializing concurrent pl-\u003ephydev writes with resolver",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2025-39905",
"datePublished": "2025-10-01T07:44:28.758Z",
"dateReserved": "2025-04-16T07:20:57.146Z",
"dateUpdated": "2025-10-01T07:44:28.758Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.1",
"vulnerability-lookup:meta": {
"nvd": "{\"cve\":{\"id\":\"CVE-2025-39905\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2025-10-01T08:15:33.370\",\"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: phylink: add lock for serializing concurrent pl-\u003ephydev writes with resolver\\n\\nCurrently phylink_resolve() protects itself against concurrent\\nphylink_bringup_phy() or phylink_disconnect_phy() calls which modify\\npl-\u003ephydev by relying on pl-\u003estate_mutex.\\n\\nThe problem is that in phylink_resolve(), pl-\u003estate_mutex is in a lock\\ninversion state with pl-\u003ephydev-\u003elock. So pl-\u003ephydev-\u003elock needs to be\\nacquired prior to pl-\u003estate_mutex. But that requires dereferencing\\npl-\u003ephydev in the first place, and without pl-\u003estate_mutex, that is\\nracy.\\n\\nHence the reason for the extra lock. Currently it is redundant, but it\\nwill serve a functional purpose once mutex_lock(\u0026phy-\u003elock) will be\\nmoved outside of the mutex_lock(\u0026pl-\u003estate_mutex) section.\\n\\nAnother alternative considered would have been to let phylink_resolve()\\nacquire the rtnl_mutex, which is also held when phylink_bringup_phy()\\nand phylink_disconnect_phy() are called. But since phylink_disconnect_phy()\\nruns under rtnl_lock(), it would deadlock with phylink_resolve() when\\ncalling flush_work(\u0026pl-\u003eresolve). Additionally, it would have been\\nundesirable because it would have unnecessarily blocked many other call\\npaths as well in the entire kernel, so the smaller-scoped lock was\\npreferred.\"}],\"metrics\":{},\"references\":[{\"url\":\"https://git.kernel.org/stable/c/0ba5b2f2c381dbec9ed9e4ab3ae5d3e667de0dc3\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/56fe63b05ec84ae6674269d78397cec43a7a295a\",\"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…