CVE-2026-72389 in Linux
Summary
by MITRE • 08/15/2026
In the Linux kernel, the following vulnerability has been resolved:
bridge: stp: Fix a potential use-after-free when deleting a bridge
The three STP timers are not supposed to be armed while the bridge is administratively down. They are synchronously deactivated when the bridge is put administratively down and the various call sites check for 'IFF_UP' before arming them.
This check is missing from br_topology_change_detection() and it is possible to engineer a situation in which the topology change timer is armed while the bridge is administratively down, resulting in a use-after-free [1] when the bridge is deleted.
Fix by adding the missing check and for good measures synchronously shutdown the three timers when the bridge is deleted.
[1]
ODEBUG: free active (active state 0) object: ffff88811662b9b0 object type: timer_list hint: br_topology_change_timer_expired (net/bridge/br_stp_timer.c:120) WARNING: lib/debugobjects.c:629 at debug_print_object+0x1bc/0x450, CPU#9: ip/359
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/15/2026
This vulnerability exists within the Linux kernel's bridge implementation specifically in the Spanning Tree Protocol (STP) handling code. The issue manifests as a use-after-free condition that occurs during bridge deletion operations when the bridge is administratively down but STP timers remain improperly armed. The root cause stems from an inconsistent application of administrative state checks within the STP timer management functions, creating a scenario where timer activation bypasses the normal administrative down state validation.
The technical flaw arises from the br_topology_change_detection() function which fails to verify the bridge's administrative up status before arming the topology change timer. While other timer management functions properly check for IFF_UP flag before enabling timers, this specific function omits the critical administrative state validation. When a bridge transitions to administratively down state, the system should synchronously deactivate all STP timers through proper shutdown procedures, but the missing check allows the topology change timer to remain armed despite the bridge being administratively inactive.
The operational impact of this vulnerability is significant as it creates a potential system crash or memory corruption scenario when attempting to delete a bridge that has been administratively shut down. The use-after-free condition occurs because the timer expiration handler references freed memory structures, specifically the timer_list object that has already been deallocated during bridge deletion. The debug output indicates that the freed object type is timer_list with the hint pointing to br_topology_change_timer_expired function at line 120 of net/bridge/br_stp_timer.c, demonstrating that the timer handler attempts to access memory that no longer belongs to the system.
This vulnerability aligns with CWE-416 Use After Free, which describes a condition where an application continues to use a pointer after the memory it points to has been freed. The issue also maps to ATT&CK technique T1059.007 Command and Scripting Interpreter: Python, as exploitation may involve crafting specific network conditions to trigger the race condition, though the primary attack vector is through normal bridge management operations. The fix implements proper administrative state validation in br_topology_change_detection() and ensures synchronous shutdown of all three STP timers during bridge deletion operations. This approach prevents timer activation when the bridge is administratively down while maintaining proper cleanup procedures that prevent memory access violations during system shutdown.
The remediation strategy addresses both the immediate root cause and defensive measures by adding the missing administrative state check to ensure consistent timer management across all STP functions. The synchronous shutdown of all three timers during deletion provides comprehensive protection against similar issues in other timer functions within the same subsystem. This fix maintains backward compatibility while preventing the memory corruption scenario that could lead to system instability or privilege escalation in scenarios where malicious actors might attempt to exploit the timing race condition through bridge management operations.