CVE-2025-39905: net: phylink: add lock for serializing concurrent pl->phydev writes with resolver
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.
Security readout for executives and security teams
Plain-English summary
CVE-2025-39905 is a Linux kernel race condition in the phylink networking code. A local low-privileged user may be able to trigger unsafe concurrent access inside the kernel. The CVE rates potential confidentiality, integrity, and availability impact as high, but exploitation requires local access and high attack complexity.
Executive priority
Handle this in the normal high-severity kernel patch cycle, faster for multi-user or shared infrastructure. There is no sourced evidence of active exploitation, but kernel race bugs can have broad business impact if reachable by local users.
Technical view
The issue is CWE-362 in net/phylink. phylink_resolve() relies on pl->state_mutex while pl->phydev can be changed by phylink_bringup_phy() or phylink_disconnect_phy(), creating a race and lock-order problem with pl->phydev->lock. The fix adds a smaller-scoped lock to serialize pl->phydev writes with resolver activity.
Likely exposure
Exposure is limited to systems running Linux kernel versions marked affected in the CVE data. Exact distro impact depends on kernel backports. The vulnerable area is kernel phylink networking code, so this is not a remotely reachable application flaw by itself.
Exploitation context
The source bundle does not show CISA KEV listing or active exploitation. The CVSS vector is local, high complexity, low privileges, and no user interaction. Treat it as important for shared systems, container hosts, and appliances where untrusted local users exist.
Researcher notes
Evidence is limited to the CVE record and two Linux stable commit references. The affected version data is sparse and lacks CPEs, so distribution-level validation is required. Avoid assuming exploitability beyond the CVSS local, high-complexity model.
Mitigation direction
Apply a vendor or distribution kernel update containing the stable phylink fix.
Track Linux and distribution advisories for exact fixed package versions.
Prioritize shared Linux hosts, container hosts, and network appliances first.
If no update is available, reduce untrusted local shell access.
Confirm whether your kernel vendor backported the referenced commits.
Validation and detection
Inventory Linux kernel versions across servers, appliances, and images.
Compare running kernels against vendor advisories for CVE-2025-39905.
Check whether the referenced stable commits are present or backported.
Validate after patching that systems boot the updated kernel.
Record exceptions where vendor impact analysis is still pending.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cwe · low confidence lookup
CWE-362: Exact CWE lookup
Use the exact CWE identifier as the starting point before reviewing related ATT&CK behavior. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
1CVSS vectors
3Timeline events
1ADP providers
3Source links
SSVC decision data
CISA-ADPCISA Coordinator
Timestamp
Version
2.0.3
Exploitation: noneAutomatable: noTechnical Impact: total
CVSS vector scores
1 official score
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.
CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.
CWE-362 · source CWE mapping
Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')
Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.