CVE-2025-38149 in Linux
Summary
by MITRE • 07/03/2025
In the Linux kernel, the following vulnerability has been resolved:
net: phy: clear phydev->devlink when the link is deleted
There is a potential crash issue when disabling and re-enabling the network port. When disabling the network port, phy_detach() calls device_link_del() to remove the device link, but it does not clear phydev->devlink, so phydev->devlink is not a NULL pointer. Then the network port is re-enabled, but if phy_attach_direct() fails before calling device_link_add(), the code jumps to the "error" label and calls phy_detach(). Since phydev->devlink retains the old value from the previous attach/detach cycle, device_link_del() uses the old value, which accesses a NULL pointer and causes a crash. The simplified crash log is as follows.
[ 24.702421] Call trace:
[ 24.704856] device_link_put_kref+0x20/0x120
[ 24.709124] device_link_del+0x30/0x48
[ 24.712864] phy_detach+0x24/0x168
[ 24.716261] phy_attach_direct+0x168/0x3a4
[ 24.720352] phylink_fwnode_phy_connect+0xc8/0x14c
[ 24.725140] phylink_of_phy_connect+0x1c/0x34
Therefore, phydev->devlink needs to be cleared when the device link is deleted.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/26/2026
This vulnerability exists in the Linux kernel's phy subsystem where a race condition occurs during network port disable and re-enable operations. The issue stems from improper cleanup of the phydev->devlink pointer during the phy_detach() function execution, creating a persistent reference to a previously deleted device link. When network ports are disabled, the phy_detach() function correctly calls device_link_del() to remove the device link relationship but fails to clear the phydev->devlink pointer, leaving it pointing to freed memory. This creates a dangerous state where subsequent re-enable operations can trigger crashes due to accessing invalid memory locations.
The technical flaw manifests when a network port undergoes a disable-re-enable cycle. During the initial disable operation, device_link_del() properly removes the device link relationship but leaves phydev->devlink unmodified, maintaining a reference to the old device link structure. When the port is re-enabled, the phy_attach_direct() function attempts to establish a new connection, but if this process fails before successfully calling device_link_add(), the code branches to an error handler that invokes phy_detach() again. Since phydev->devlink still contains the old reference from the previous cycle, the second phy_detach() call attempts to delete a device link using the stale pointer, resulting in a NULL pointer dereference and system crash.
The operational impact of this vulnerability is significant for network infrastructure systems that frequently disable and re-enable network ports, particularly in dynamic environments such as data centers, network switches, and embedded systems where port reconfiguration occurs regularly. The crash occurs during normal network port management operations, making it particularly dangerous as it can lead to service disruption and system instability. This vulnerability affects the reliability of network subsystems and could be exploited by malicious actors to cause denial of service conditions or potentially escalate privileges through kernel memory corruption.
The root cause of this vulnerability aligns with CWE-476, which describes NULL pointer dereference issues in software systems. The problem also relates to CWE-823, indicating improper handling of references to objects that have been freed or deleted. From an ATT&CK framework perspective, this vulnerability could be leveraged in the privilege escalation and denial of service phases, potentially allowing attackers to disrupt network services or gain unauthorized access to kernel memory. The fix requires modifying the phy_detach() function to explicitly clear the phydev->devlink pointer after calling device_link_del(), ensuring that subsequent operations do not attempt to access stale references. This remediation follows best practices for memory management in kernel space and aligns with the principle of proper resource cleanup during object destruction or removal operations.