GHSA-3W4M-C8RQ-62JJ
Vulnerability from github – Published: 2025-10-01 09:30 – Updated: 2025-12-12 21:31In 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.
{
"affected": [],
"aliases": [
"CVE-2025-39905"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-01T08:15:33Z",
"severity": "HIGH"
},
"details": "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.",
"id": "GHSA-3w4m-c8rq-62jj",
"modified": "2025-12-12T21:31:33Z",
"published": "2025-10-01T09:30:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39905"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0ba5b2f2c381dbec9ed9e4ab3ae5d3e667de0dc3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/56fe63b05ec84ae6674269d78397cec43a7a295a"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.