CVE-2025-39905
net: phylink: add lock for serializing concurrent pl->phydev writes with resolver
Published:
10/1/2025
Last updated:
1/14/2026
Reserved:
4/16/2025
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.
CNA assigner:
Linux (416baaa9-dc9f-4396-8d5f-8c081fb06d67)
Requested by:
n/a
Products affected (4)
| Product |
Vendor |
Version |
| Linux |
Linux
|
< 10.0.22000.556
|
| Linux |
Linux
|
< 10.0.19044.1586
|
| Linux |
Linux
|
2.1(1)
|
| Linux |
Linux
|
2.0(1)
|