CVE-2025-39915
published 2025-10-01CVE-2025-39915: In the Linux kernel, the following vulnerability has been resolved: net: phy: transfer phy_config_inband() locking responsibility to phylink Problem…
PriorityP420medium5.5CVSS 3.1
AVLACLPRLUINSUCNINAH
EPSS
0.09%
0.7th percentile
In the Linux kernel, the following vulnerability has been resolved:
net: phy: transfer phy_config_inband() locking responsibility to phylink
Problem description
Lockdep reports a possible circular locking dependency (AB/BA) between
&pl->state_mutex and &phy->lock, as follows.
phylink_resolve() // acquires &pl->state_mutex
-> phylink_major_config()
-> phy_config_inband() // acquires &pl->phydev->lock
whereas all the other call sites where &pl->state_mutex and
&pl->phydev->lock have the locking scheme reversed. Everywhere else,
&pl->phydev->lock is acquired at the top level, and &pl->state_mutex at
the lower level. A clear example is phylink_bringup_phy().
The outlier is the newly introduced phy_config_inband() and the existing
lock order is the correct one. To understand why it cannot be the other
way around, it is sufficient to consider phylink_phy_change(), phylink's
callback from the PHY device's phy->phy_link_change() virtual method,
invoked by the PHY state machine.
phy_link_up() and phy_link_down(), the (indirect) callers of
phylink_phy_change(), are called with &phydev->lock acquired.
Then phylink_phy_change() acquires its own &pl->state_mutex, to
serialize changes made to its pl->phy_state and pl->link_config.
So all other instances of &pl->state_mutex and &phydev->lock must be
consistent with this order.
Problem impact
I think the kernel runs a serious deadlock risk if an existing
phylink_resolve() thread, which results in a phy_config_inband() call,
is concurrent with a phy_link_up() or phy_link_down() call, which will
deadlock on &pl->state_mutex in phylink_phy_change(). Practically
speaking, the impact may be limited by the slow speed of the medium
auto-negotiation protocol, which makes it unlikely for the current state
to still be unresolved when a new one is detected, but I think the
problem is there. Nonetheless, the problem was discovered using lockdep.
Proposed solution
Practically speaking, the phy_config_inband() requirement of having
ph
Affected
7 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| debian | linux | < linux 6.16.8-1 (forky) | linux 6.16.8-1 (forky) |
| linux | linux | — | — |
| linux | linux | >= 5fd0f1a02e750e2db4038dee60edea669ce5aab1 < 052ac41c379c8b87629808be612a482b2d0ae283 | 052ac41c379c8b87629808be612a482b2d0ae283 |
| linux | linux | >= 5fd0f1a02e750e2db4038dee60edea669ce5aab1 < e2a10daba84968f6b5777d150985fd7d6abc9c84 | e2a10daba84968f6b5777d150985fd7d6abc9c84 |
| linux | linux_kernel | — | — |
| linux | linux_kernel | >= 0 < 6.16.8-1 | 6.16.8-1 |
| linux | linux_kernel | >= 6.14 < 6.16.8 | 6.16.8 |
CVSS provenance
nvdv3.15.5MEDIUMCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
osv5.5MEDIUM
vendor_debian5.5LOW
vendor_redhat5.5MEDIUM
Stop checking back — get the weekly exploitation signal.
Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.
Red Hat
kernel: net: phy: transfer phy_config_inband() locking responsibility to phylink
vendor_redhat·2025-10-01·CVSS 5.5
CVE-2025-39915 [MEDIUM] CWE-833 kernel: net: phy: transfer phy_config_inband() locking responsibility to phylink
kernel: net: phy: transfer phy_config_inband() locking responsibility to phylink
In the Linux kernel, the following vulnerability has been resolved:
net: phy: transfer phy_config_inband() locking responsibility to phylink
Problem description
Lockdep reports a possible circular locking dependency (AB/BA) between
&pl->state_mutex and &phy->lock, as follows.
phylink_resolve() // acquires &pl->state_mutex
-> phylink_major_config()
-> phy_config_inband() // acquires &pl->phydev->lock
whereas all the other call sites where &pl->state_mutex and
&pl->phydev->lock have the locking scheme reversed. Everywhere else,
&pl->phydev->lock is acquired at the top level, and &pl->state_mutex at
the lower level. A clear example is phylink_bringup_phy().
The outlier is the newly introduced phy_config_inband()
Debian
CVE-2025-39915: linux - In the Linux kernel, the following vulnerability has been resolved: net: phy: t...
vendor_debian·2025·CVSS 5.5
CVE-2025-39915 [MEDIUM] CVE-2025-39915: linux - In the Linux kernel, the following vulnerability has been resolved: net: phy: t...
In the Linux kernel, the following vulnerability has been resolved: net: phy: transfer phy_config_inband() locking responsibility to phylink Problem description =================== Lockdep reports a possible circular locking dependency (AB/BA) between &pl->state_mutex and &phy->lock, as follows. phylink_resolve() // acquires &pl->state_mutex -> phylink_major_config() -> phy_config_inband() // acquires &pl->phydev->lock whereas all the other call sites where &pl->state_mutex and &pl->phydev->lock have the locking scheme reversed. Everywhere else, &pl->phydev->lock is acquired at the top level, and &pl->state_mutex at the lower level. A clear example is phylink_bringup_phy(). The outlier is the newly introduced phy_config_inband() and the existing lock order is the correct one. To understand
GHSA
GHSA-m8cc-c87r-9qr2: In the Linux kernel, the following vulnerability has been resolved:
net: phy: transfer phy_config_inband() locking responsibility to phylink
Problem
ghsa_unreviewed·2025-10-01
CVE-2025-39915 [MEDIUM] CWE-667 GHSA-m8cc-c87r-9qr2: In the Linux kernel, the following vulnerability has been resolved:
net: phy: transfer phy_config_inband() locking responsibility to phylink
Problem
In the Linux kernel, the following vulnerability has been resolved:
net: phy: transfer phy_config_inband() locking responsibility to phylink
Problem description
Lockdep reports a possible circular locking dependency (AB/BA) between
&pl->state_mutex and &phy->lock, as follows.
phylink_resolve() // acquires &pl->state_mutex
-> phylink_major_config()
-> phy_config_inband() // acquires &pl->phydev->lock
whereas all the other call sites where &pl->state_mutex and
&pl->phydev->lock have the locking scheme reversed. Everywhere else,
&pl->phydev->lock is acquired at the top level, and &pl->state_mutex at
the lower level. A clear example is phylink_bringup_phy().
The outlier is the newly introduced phy_config_inband() and the existing
lock order is the correct one. To understand why it cannot
OSV
CVE-2025-39915: In the Linux kernel, the following vulnerability has been resolved: net: phy: transfer phy_config_inband() locking responsibility to phylink Problem d
osv·2025-10-01·CVSS 5.5
CVE-2025-39915 [MEDIUM] CVE-2025-39915: In the Linux kernel, the following vulnerability has been resolved: net: phy: transfer phy_config_inband() locking responsibility to phylink Problem d
In the Linux kernel, the following vulnerability has been resolved: net: phy: transfer phy_config_inband() locking responsibility to phylink Problem description =================== Lockdep reports a possible circular locking dependency (AB/BA) between &pl->state_mutex and &phy->lock, as follows. phylink_resolve() // acquires &pl->state_mutex -> phylink_major_config() -> phy_config_inband() // acquires &pl->phydev->lock whereas all the other call sites where &pl->state_mutex and &pl->phydev->lock have the locking scheme reversed. Everywhere else, &pl->phydev->lock is acquired at the top level, and &pl->state_mutex at the lower level. A clear example is phylink_bringup_phy(). The outlier is the newly introduced phy_config_inband() and the existing lock order is the correct one. To understand
No detection rules found.
No public exploits indexed.
2025-10-01
Published