CVE-2026-72307 in Linux
Summary
by MITRE • 08/15/2026
In the Linux kernel, the following vulnerability has been resolved:
mlxsw: fix refcount leak in mlxsw_sp_vrs_lpm_tree_replace()
When mlxsw_sp_vrs_lpm_tree_replace() fails after replacing some VRs, the error rollback loop does not correctly revert the preceding replacements. The loop decrements the index but fails to update the vr pointer, which still points to the VR that caused the failure. As a result, the condition and the rollback call always operate on the same VR, potentially calling mlxsw_sp_vr_lpm_tree_replace() multiple times on it while never rolling back the earlier VRs. Those VRs continue to hold a reference to new_tree acquired via mlxsw_sp_lpm_tree_hold(), leaking the reference count of new_tree.
Fix by reinitializing vr inside the error loop with the updated index:
vr = &mlxsw_sp->router->vrs[i];
so that the loop correctly iterates over all VRs that were actually replaced.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/15/2026
This vulnerability exists within the mlxsw network driver in the Linux kernel, specifically affecting the mlxsw_sp_vrs_lpm_tree_replace() function responsible for managing Layer 3 routing table operations. The issue stems from improper reference count management during error rollback procedures when replacing virtual routers within the LPM (Longest Prefix Match) tree structure. When a failure occurs during the replacement process, the system attempts to roll back previous successful replacements but encounters a critical flaw in its iteration logic.
The technical flaw manifests as a reference count leak in the mlxsw_sp_lpm_tree_hold() function call chain, where the vr pointer remains anchored to the failing VR element while the loop index correctly decrements. This creates a scenario where the error rollback mechanism continuously operates on the same failing VR instead of properly iterating through all previously replaced VRs. The condition and rollback calls repeatedly target the identical VR, causing multiple invocations of mlxsw_sp_vr_lpm_tree_replace() on the same element while never actually reverting the earlier successful replacements.
This vulnerability directly relates to CWE-404, which addresses improper resource management and reference counting issues in kernel space operations. The flaw represents a classic case of resource leak through incorrect loop iteration logic that violates proper error handling protocols. The operational impact includes sustained memory pressure due to unreleased reference counts, potentially leading to system instability or performance degradation when multiple routing table operations fail sequentially. The leaked references to new_tree objects accumulate over time, creating a gradual resource exhaustion problem that may not manifest immediately but progressively impacts system reliability.
The fix implements a proper reinitialization of the vr pointer within the error rollback loop by explicitly setting vr = &mlxsw_sp->router->vrs[i] at each iteration step. This ensures that the loop correctly references each VR element that was actually replaced, allowing proper rollback operations to occur on all affected virtual routers. The solution addresses the fundamental issue where the loop logic failed to maintain consistency between the index counter and the vr pointer, creating a state where the rollback mechanism could not properly traverse the sequence of replacements that needed to be undone.
This vulnerability demonstrates the critical importance of proper error handling in kernel drivers, particularly when managing complex data structures like LPM trees with multiple reference counting operations. The fix aligns with ATT&CK framework techniques related to privilege escalation through resource exhaustion and memory management flaws, though it specifically addresses a denial-of-service scenario rather than direct exploitation. The implementation requires careful attention to loop semantics and pointer management in kernel code, where even subtle logic errors can result in persistent resource leaks that degrade system performance over time. The remediation approach follows established best practices for error rollback mechanisms in kernel space, ensuring that all successfully modified elements are properly reverted when failures occur during batch operations.