CVE-2026-98594 in Linux
Summary
by MITRE • 10/18/2026
In the Linux kernel, the following vulnerability has been resolved:
tg3: clean up PHYLIB resources on probe failure
tg3_get_invariants() can register an MDIO bus and connect a PHY for USE_PHYLIB devices. If tg3_init_one() later fails, its common error path releases the mappings and netdev without undoing those PHYLIB resources.
Disconnect the PHY and unregister the MDIO bus before the remaining teardown. Guard PHY cleanup with USE_PHYLIB to match tg3_phy_init(), and call tg3_mdio_fini() unconditionally to match tg3_mdio_init(). The existing IS_CONNECTED and MDIOBUS_INITED flags make both helpers safe when initialization only completed partially.
This issue was identified during our ongoing static-analysis research while reviewing kernel code.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/18/2026
The Linux kernel driver for Broadcom NetXtreme II network adapters, known as tg3, contains a resource management flaw that occurs during the device probe phase. This vulnerability arises from an inconsistency in how hardware resources are allocated and deallocated when initialization fails partway through the process. Specifically, the function tg3_get_invariants is responsible for registering an MDIO bus and connecting to a PHY (Physical Layer) component if the system configuration utilizes the PHYLIB subsystem. These steps are critical for establishing communication with the physical network interface hardware. However, if the subsequent function tg3_init_one encounters an error and triggers its common failure path, the driver correctly releases memory mappings and the net_device structure but fails to reverse the earlier PHYLIB operations. This oversight results in a resource leak where the MDIO bus remains registered and the PHY connection is not properly severed, leaving dangling references within the kernel's device model subsystem.
From a technical perspective, this flaw represents an improper cleanup mechanism that leads to state inconsistency during error handling paths. The root cause lies in the lack of symmetry between initialization and teardown routines. While tg3_mdio_init correctly sets up the MDIO bus, its counterpart for cleanup was not being invoked unconditionally upon failure. By disconnecting the PHY and unregistering the MDIO bus before proceeding with other teardown steps, and by guarding these actions with a check for USE_PHYLIB to match the initialization logic, the driver ensures that all allocated resources are properly released regardless of where in the probe sequence an error occurs. The existing flags IS_CONNECTED and MDIOBUS_INITED provide safe guards, ensuring that cleanup functions do not attempt to operate on uninitialized or already cleaned-up structures, thereby preventing potential null pointer dereferences or double-free errors during this partial initialization scenario.
The operational impact of this vulnerability is primarily related to resource exhaustion and system stability over time. Although a single instance might seem minor, repeated probe failures—such as those caused by hardware incompatibilities, driver conflicts, or hot-plug events in virtualized environments—can accumulate leaked MDIO bus registrations and PHY references. This gradual accumulation can lead to memory leaks within the kernel space, potentially degrading system performance or causing allocation failures for other drivers that rely on similar subsystems. Furthermore, stale device nodes left in the sysfs hierarchy due to incomplete teardown can confuse user-space tools like udev, leading to incorrect device identification or management issues. In severe cases, if the leaked resources interfere with subsequent driver loads or hardware re-initialization attempts, it could result in network interface instability or failure to bring up new devices until a system reboot is performed.
This issue aligns with CWE-401, which describes missing release of memory after successful allocation, and specifically relates to improper cleanup on error paths within software components. In the context of the MITRE ATT&CK framework for enterprise security, this type of vulnerability does not directly facilitate lateral movement or privilege escalation but contributes to a broader attack surface by reducing system reliability and availability. Attackers could potentially exploit resource exhaustion patterns in high-churn environments to induce denial-of-service conditions against network infrastructure components that rely on stable driver behavior. Mitigation involves applying the kernel patch that ensures tg3_mdio_fini is called unconditionally during error paths, thereby restoring symmetry between initialization and cleanup routines. System administrators should ensure their Linux kernels are updated with this fix applied, particularly in environments where frequent device insertion or removal occurs, to maintain long-term stability of network subsystems.