CVE-2025-39905
published 2025-10-01CVE-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…
PriorityP428high7CVSS 3.1
AVLACHPRLUINSUCHIHAH
EPSS
0.10%
1.1th percentile
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.
Affected
19 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 < 56fe63b05ec84ae6674269d78397cec43a7a295a | 56fe63b05ec84ae6674269d78397cec43a7a295a |
| linux | linux | >= 5fd0f1a02e750e2db4038dee60edea669ce5aab1 < 0ba5b2f2c381dbec9ed9e4ab3ae5d3e667de0dc3 | 0ba5b2f2c381dbec9ed9e4ab3ae5d3e667de0dc3 |
| linux | linux_kernel | < 6.16.8 | 6.16.8 |
| linux | linux_kernel | — | — |
| linux | linux_kernel | >= 0 < 6.16.8-1 | 6.16.8-1 |
| msrc | azl3_kernel_6.6.104.2-4_on_azure_linux_3.0 | — | — |
| msrc | azl3_kernel_6.6.112.1-2_on_azure_linux_3.0 | — | — |
| msrc | azl3_kernel_6.6.117.1-1_on_azure_linux_3.0 | — | — |
| msrc | azl3_kernel_6.6.119.3-1_on_azure_linux_3.0 | — | — |
| msrc | azl3_kernel_6.6.119.3-3_on_azure_linux_3.0 | — | — |
| msrc | azl3_kernel_6.6.121.1-1_on_azure_linux_3.0 | — | — |
| msrc | azl3_kernel_6.6.126.1-1_on_azure_linux_3.0 | — | — |
| msrc | azl3_kernel_6.6.130.1-3_on_azure_linux_3.0 | — | — |
| msrc | azl3_kernel_6.6.96.2-2_on_azure_linux_3.0 | — | — |
| msrc | cbl2_kernel_5.15.186.1-1_on_cbl_mariner_2.0 | — | — |
| msrc | cbl2_kernel_5.15.200.1-1_on_cbl_mariner_2.0 | — | — |
| msrc | cbl2_kernel_5.15.202.1-1_on_cbl_mariner_2.0 | — | — |
CVSS provenance
nvdv3.17.0HIGHCVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
osv7.0HIGH
vendor_msrc7.1HIGH
vendor_debian7.0LOW
vendor_redhat7.0HIGH
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.
Microsoft
net: phylink: add lock for serializing concurrent pl->phydev writes with resolver
vendor_msrc·2025-10-14·CVSS 7.1
CVE-2025-39905 [HIGH] net: phylink: add lock for serializing concurrent pl->phydev writes with resolver
net: phylink: add lock for serializing concurrent pl->phydev writes with resolver
FAQ: Is Azure Linux the only Microsoft product that includes this open-source library and is therefore potentially affected by this vulnerability?
One of the main benefits to our customers who choose to use the Azure Linux distro is the commitment to keep it up to date with the most recent and most secure versions of the open source libraries with which the distro is composed. Microsoft is committed to transparency in this work which is why we began publishing CSAF/VEX in October 2025. See this blog post for more information. If impact to additional products is identified, we will update the CVE to reflect this.
Mariner: Mariner
Linux: Linux
Customer Action Required: Yes
Red Hat
kernel: net: phylink: add lock for serializing concurrent pl->phydev writes with resolver
vendor_redhat·2025-10-01·CVSS 7.0
CVE-2025-39905 [HIGH] CWE-664 kernel: net: phylink: add lock for serializing concurrent pl->phydev writes with resolver
kernel: 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
Debian
CVE-2025-39905: linux - In the Linux kernel, the following vulnerability has been resolved: net: phylin...
vendor_debian·2025·CVSS 7.0
CVE-2025-39905 [HIGH] CVE-2025-39905: linux - In the Linux kernel, the following vulnerability has been resolved: net: phylin...
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) sect
GHSA
GHSA-3w4m-c8rq-62jj: In the Linux kernel, the following vulnerability has been resolved:
net: phylink: add lock for serializing concurrent pl->phydev writes with resolver
ghsa_unreviewed·2025-10-01
CVE-2025-39905 [HIGH] CWE-362 GHSA-3w4m-c8rq-62jj: In the Linux kernel, the following vulnerability has been resolved:
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)
OSV
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
osv·2025-10-01·CVSS 7.0
CVE-2025-39905 [HIGH] 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
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) sect
No detection rules found.
No public exploits indexed.
Bugzilla
CVE-2025-39905 kernel: net: phylink: add lock for serializing concurrent pl->phydev writes with resolver
bugzilla·2025-10-01·CVSS 7.0
CVE-2025-39905 [HIGH] CVE-2025-39905 kernel: net: phylink: add lock for serializing concurrent pl->phydev writes with resolver
CVE-2025-39905 kernel: 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
Bleepingcomputer
Microsoft October 2025 Patch Tuesday fixes 6 zero-days, 172 flaws
blogs_bleepingcomputer·2025-10-14·CVSS 7.8
[HIGH] Microsoft October 2025 Patch Tuesday fixes 6 zero-days, 172 flaws
## Microsoft October 2025 Patch Tuesday fixes 6 zero-days, 172 flaws
## Lawrence Abrams
80 Elevation of Privilege Vulnerabilities
11 Security Feature Bypass Vulnerabilities
31 Remote Code Execution Vulnerabilities
28 Information Disclosure Vulnerabilities
11 Denial of Service Vulnerabilities
10 Spoofing Vulnerabilities
When BleepingComputer reports on the Patch Tuesday security updates, we only count those released today by Microsoft. Therefore, the number of flaws does not include those fixed in Azure, Mariner, Microsoft Edge, and other vulnerabilities earlier this month.
Notably, Windows 10 reaches the end of support today , with this being the last Patch Tuesday where Microsoft provides free security updates to the venerable operating system.
To continue receiving security upd
2025-10-01
Published