Linux Kernel up to 6.16.7 phylink_resolve null pointer dereference

Summaryinfo

A vulnerability was found in Linux Kernel up to 6.16.7. It has been classified as critical. Impacted is the function phylink_resolve. This manipulation causes null pointer dereference. This vulnerability is registered as CVE-2025-39905. No exploit is available. Upgrading the affected component is recommended.

Detailsinfo

A vulnerability classified as critical was found in Linux Kernel up to 6.16.7. Affected by this vulnerability is the function phylink_resolve. The manipulation with an unknown input leads to a null pointer dereference vulnerability. The CWE definition for the vulnerability is CWE-476. A NULL pointer dereference occurs when the application dereferences a pointer that it expects to be valid, but is NULL, typically causing a crash or exit. As an impact it is known to affect availability. The summary by CVE is:

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.

The advisory is shared at git.kernel.org. This vulnerability is known as CVE-2025-39905 since 04/16/2025. The exploitation appears to be difficult. Technical details are known, but no exploit is available.

The vulnerability scanner Nessus provides a plugin with the ID 282630 (Oracle Linux 10 : kernel (ELSA-2026-0453)), which helps to determine the existence of the flaw in a target environment.

Upgrading to version 6.16.8 eliminates this vulnerability. Applying the patch 56fe63b05ec84ae6674269d78397cec43a7a295a/0ba5b2f2c381dbec9ed9e4ab3ae5d3e667de0dc3 is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.

The vulnerability is also documented in the databases at Tenable (282630) and CERT Bund (WID-SEC-2025-2170). If you want to get the best quality for vulnerability data then you always have to consider VulDB.

Affected

• Debian Linux
• Amazon Linux 2
• Red Hat Enterprise Linux
• Ubuntu Linux
• SUSE Linux
• Oracle Linux
• SUSE openSUSE
• RESF Rocky Linux
• Open Source Linux Kernel
• Dell Secure Connect Gateway

Productinfo

Type

• Operating System

Vendor

• Linux

Name

• Kernel

Version

• 6.16.0
• 6.16.1
• 6.16.2
• 6.16.3
• 6.16.4
• 6.16.5
• 6.16.6
• 6.16.7

License

• open-source

Website

• Vendor: https://www.kernel.org/

CPE 2.3info

• 🔒
• 🔒
• 🔒

CPE 2.2info

• 🔒
• 🔒
• 🔒

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

If you want to get the best quality for vulnerability data then you always have to consider VulDB.

Discussion