CVE-2025-39905

In the Linux kernel, the following vulnerability has been resolved:

net: phylink: add lock for serializing concurrent pl->phydev writes with resolver

Currently phylinkresolve() protects itself against concurrent phylinkbringupphy() or phylinkdisconnectphy() calls which modify pl->phydev by relying on pl->statemutex.

The problem is that in phylinkresolve(), pl->statemutex is in a lock inversion state with pl->phydev->lock. So pl->phydev->lock needs to be acquired prior to pl->statemutex. But that requires dereferencing pl->phydev in the first place, and without pl->statemutex, that is racy.

Hence the reason for the extra lock. Currently it is redundant, but it will serve a functional purpose once mutexlock(&phy->lock) will be moved outside of the mutexlock(&pl->state_mutex) section.

Another alternative considered would have been to let phylinkresolve() acquire the rtnlmutex, which is also held when phylinkbringupphy() and phylinkdisconnectphy() are called. But since phylinkdisconnectphy() runs under rtnllock(), it would deadlock with phylinkresolve() 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.