CVE-2026-72391 in Linux
Summary
by MITRE • 08/15/2026
In the Linux kernel, the following vulnerability has been resolved:
net: phy: sfp: free mii_bus in sfp_i2c_mdiobus_destroy
sfp_i2c_mdiobus_create() allocates the I2C MDIO bus with mdio_i2c_alloc(), a plain (non-devm) allocation, and registers it. sfp_i2c_mdiobus_destroy() only unregisters the bus and clears sfp->i2c_mii without calling mdiobus_free(). As the only reference to the bus is then cleared, the struct mii_bus is leaked.
This is hit whenever a copper/RollBall SFP module that instantiated an MDIO bus is removed: sfp_sm_main() takes the global teardown path and calls sfp_i2c_mdiobus_destroy(). sfp_cleanup(), on driver unbind, frees sfp->i2c_mii directly, which is why the leak only triggered on module hot-removal and not on unbind.
Free the bus in sfp_i2c_mdiobus_destroy() to match the allocation done in sfp_i2c_mdiobus_create().
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/15/2026
This vulnerability represents a memory leak in the Linux kernel's SFP (Small Form-factor Pluggable) subsystem that occurs during the dynamic removal of copper or RollBall SFP modules. The issue stems from an improper cleanup routine that fails to release allocated resources, creating a persistent memory footprint within the kernel's memory management system. The vulnerability specifically affects the network PHY (Physical Layer) subsystem where SFP modules are managed through I2C MDIO bus interfaces.
The technical flaw manifests in the mismatch between allocation and deallocation functions within the SFP driver implementation. The sfp_i2c_mdiobus_create() function performs a standard allocation using mdio_i2c_alloc() which creates a mii_bus structure without device managed memory allocation. This allocation pattern is critical because it requires explicit cleanup through mdiobus_free() to properly release the memory resources. However, the corresponding sfp_i2c_mdiobus_destroy() routine only unregisters the bus and clears the reference pointer without invoking the necessary mdiobus_free() function call.
The operational impact of this vulnerability extends beyond simple memory consumption as it represents a resource leak that accumulates over time with repeated module insertion and removal operations. This type of memory leak can lead to progressive system degradation, particularly in environments where SFP modules are frequently hot-plugged and removed such as data center switches, network routers, or server infrastructure. The leak specifically occurs during the global teardown path initiated by sfp_sm_main() when processing module removal events, making it a critical issue for systems with high module turnover rates.
The vulnerability demonstrates a clear violation of proper resource management principles and aligns with CWE-401 (Improper Release of Memory before Removing Last Reference) which specifically addresses memory leaks caused by failing to release allocated resources. From an ATT&CK perspective, this represents a potential resource exhaustion vector that could be exploited to degrade system performance or availability, though the direct attack surface is limited to kernel-level operations. The fact that the leak only manifests during hot-removal rather than driver unbind indicates a specific code path issue where different cleanup routines are invoked under different conditions.
The mitigation strategy involves modifying the sfp_i2c_mdiobus_destroy() function to include the proper mdiobus_free() call that matches the allocation pattern established by sfp_i2c_mdiobus_create(). This ensures that every allocated mii_bus structure is properly released, maintaining the integrity of kernel memory management. The fix requires careful consideration of the driver's lifecycle management and proper coordination between module creation and destruction routines to prevent similar issues in related subsystems.
This vulnerability highlights the importance of symmetric allocation and deallocation patterns in kernel programming, particularly within device drivers where resource management directly impacts system stability. The issue underscores the need for comprehensive testing of hot-plug scenarios and proper verification of cleanup routines during development cycles. The memory leak can accumulate over time and potentially impact system performance under sustained module replacement operations, making it a significant concern for network infrastructure equipment that relies heavily on SFP module management.