CVE-2026-98563 in Linuxinfo

Summary

by MITRE • 10/18/2026

In the Linux kernel, the following vulnerability has been resolved:

net: phylink: record the PHY only once bringup cannot fail

phylink_bringup_phy() stores the PHY in pl->phydev before its last fallible step: on a MAC whose phylink ops implement LPI, phy_eee_rx_clock_stop() can fail with a real MDIO error. The callers unwind with phy_detach(), which knows nothing about pl->phydev, so a pointer to a PHY that is no longer attached outlives the failed connect.

What that costs depends on how the caller got here. phylink_connect_phy() goes through phylink_attach_phy(), which refuses to attach while pl->phydev is set, turning a transient MDIO error into a permanent -EBUSY. The SFP path is worse than that: sfp_sm_probe_phy() answers the failure with phy_device_remove() and phy_device_free(), and it assigns sfp->mod_phy only past that error return, so nothing clears pl->phydev and it is left pointing at a freed phy_device that phylink_resolve() and the ethtool helpers go on reading. phylink_fwnode_phy_connect() has no such check, so a later connect overwrites the stale pointer and hides the problem. A disconnect does not: phylink_disconnect_phy() hands that pointer to phy_disconnect(), and the second phy_detach() on the same PHY drops references the first one already released.

Found while making a DSA port survive a PHY whose driver arrives after the switch probes: keeping the port across a failed connect and retrying is what makes this window reachable.

Publish the pointer after the last call that can fail instead of unwinding it afterwards. Nothing between the two points reads pl->phydev, and the registration that follows cannot fail: phy_request_interrupt() falls back to polling on its own. The PHY-side state keeps the order it had, so no MDIO operation moves relative to another.

If you want to get best quality of vulnerability data, you may have to visit VulDB.

Analysis

by VulDB Data Team • 10/18/2026

The vulnerability in question resides within the Linux kernel's network subsystem, specifically affecting the phylink framework which manages connections between MACs and physical layer devices. This issue is classified as a Use-After-Free condition, corresponding to CWE-416, where a pointer continues to be used after it has been freed or invalidated. The root cause lies in the sequence of operations within the phylink_bringup_phy function, which attempts to establish a connection between a MAC and its associated PHY device. During this process, the framework stores a reference to the PHY device in the pl->phydev field before executing all necessary initialization steps that could potentially fail. Specifically, when dealing with MACs that implement Low Power Idle (LPI) functionality via phylink operations, the function calls phy_eee_rx_clock_stop(), which interacts with hardware through MDIO bus transactions and can return an error code if a communication failure occurs.

When such a transient MDIO error is encountered during this critical phase, the caller initiates an unwinding process to clean up resources. However, the cleanup routine phy_detach() operates under the assumption that it handles detachment from a properly attached state. It does not account for the fact that pl->phydev may have been set but never fully established in a stable attachment context due to the preceding failure. Consequently, if the connection attempt fails after pl->phydev has been assigned but before successful initialization is complete, the pointer remains stored within the phylink structure even though the underlying PHY device might be detached or freed by higher-level management logic. This creates a dangling pointer scenario where subsequent operations continue to reference memory that may no longer belong to an active object.

The operational impact of this flaw varies significantly depending on which code path triggered the failure, leading to different severity levels and potential system stability issues. In cases involving phylink_connect_phy(), the issue manifests as a denial-of-service condition due to resource exhaustion logic. The function phylink_attach_phy() contains checks that prevent re-attachment if pl->phydev is already set. Therefore, when a transient error causes an unwind but leaves pl->phydev populated, subsequent connection attempts are rejected with an -EBUSY error code. This effectively locks the network interface from functioning correctly until the system state is manually reset or rebooted, as the framework incorrectly believes a PHY is still attached despite the failed initialization.

The situation becomes more critical and dangerous in scenarios involving SFP (Small Form-factor Pluggable) modules, where the vulnerability leads to actual memory corruption risks through use-after-free conditions. In this path, sfp_sm_probe_phy() handles connection failures by invoking phy_device_remove() followed by phy_device_free(), which deallocates the PHY device structure from kernel memory. Crucially, the assignment of sfp->mod_phy occurs only after these cleanup steps have completed and returned an error code. Because pl->phydev was set earlier in the bringup process but never cleared upon failure, it continues to point to the now-freed phy_device structure. Subsequent calls to phylink_resolve() or ethtool helpers may then read from this invalid memory address, potentially leading to kernel panics, data corruption, or arbitrary code execution if an attacker can influence the contents of that freed memory region through heap spraying techniques.

Furthermore, other connection paths such as phylink_fwnode_phy_connect() lack protective checks against stale pointers, allowing later connect attempts to overwrite pl->phydev and temporarily mask the issue until a disconnect operation occurs. When phylink_disconnect_phy() is eventually called, it passes the stale pointer to phy_disconnect(), which in turn calls phy_detach(). This results in double-freeing references or dropping reference counts on objects that have already been released by previous cleanup routines, further destabilizing kernel memory management structures. These issues were identified during efforts to ensure Distributed Switch Architecture ports could survive PHY driver initialization delays and retries, highlighting how race conditions and error handling gaps can expose deep-seated logic flaws in complex subsystems like network drivers.

To mitigate this vulnerability, the primary remediation strategy involves reordering operations within phylink_bringup_phy() so that pl->phydev is updated only after all fallible steps have successfully completed. By publishing the pointer to the PHY device exclusively after the last call that can fail, such as phy_eee_rx_clock_stop(), the framework ensures that no dangling references are left behind in case of error conditions. The registration process following this point relies on phy_request_interrupt(), which includes internal fallback mechanisms for polling if interrupt requests cannot be established immediately, thereby eliminating a potential failure point and ensuring state consistency. This approach maintains the correct order of MDIO operations while preventing the storage of invalid pointers during transient errors.

From a broader security perspective, this vulnerability aligns with ATT&CK techniques related to exploitation of software vulnerabilities in operating systems or drivers. The ability to trigger use-after-free conditions through network interface configuration changes represents a significant risk for local privilege escalation if an unprivileged user can manipulate PHY attachment sequences via standard networking tools like ethtool. System administrators and developers should ensure that kernel updates incorporating this fix are applied promptly, particularly on embedded devices using SFP modules or complex switch architectures where dynamic port configurations are common. Regular auditing of error handling paths in network subsystems is essential to prevent similar logic errors from persisting in other components of the Linux networking stack.

Responsible

Linux

Reservation

09/25/2026

Disclosure

10/18/2026

Moderation

accepted

EPSS

0.00000

KEV

no

Activities

very low

Sources

Are you interested in using VulDB?

Download the whitepaper to learn more about our service!