CVE-2025-39905
Unknown Unknown - Not Provided
BaseFortify

Publication date: 2025-10-01

Last updated on: 2025-12-12

Assigner: kernel.org

Description
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.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2025-10-01
Last Modified
2025-12-12
Generated
2026-05-07
AI Q&A
2025-10-01
EPSS Evaluated
2026-05-05
NVD
Affected Vendors & Products
Showing 6 associated CPEs
Vendor Product Version / Range
linux linux_kernel to 6.16.8 (exc)
linux linux_kernel 6.17
linux linux_kernel 6.17
linux linux_kernel 6.17
linux linux_kernel 6.17
linux linux_kernel 6.17
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-362 The product contains a concurrent code sequence that requires temporary, exclusive access to a shared resource, but a timing window exists in which the shared resource can be modified by another code sequence operating concurrently.
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability involves a race condition in the Linux kernel's phylink component where concurrent writes to pl->phydev are not properly serialized. The existing locking mechanism (pl->state_mutex) is in a lock inversion state with pl->phydev->lock, causing potential race conditions when dereferencing pl->phydev without holding pl->state_mutex. The fix adds an extra lock to properly serialize these concurrent writes and avoid race conditions, preventing deadlocks and ensuring safer access to shared resources.


How can this vulnerability impact me? :

This vulnerability can lead to race conditions and potential deadlocks in the Linux kernel's network subsystem, which may cause system instability, crashes, or unpredictable behavior in network device management. Such issues could affect the reliability and availability of systems running affected Linux kernel versions.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart