A Linux bridge bug left active timers inside memory that was already freed up.A public proof of concept (PoC) showed a flaw where the Linux kernel’s bridge STP code could use memory after it was released, causing crashes or memory problems.
Affected Versions: Linux Kernel prior to patch 2a00517db8de4be7df3d483b215c5544fb30a191
Think of Linux creating a small room for a network bridge with several clocks that keep track of network activity.
The room is then removed, but one of those clocks is still running.A few seconds later, it tries to enter a room that no longer exists.
Researchers found a use-after-free bug in the Linux bridge system that affects the kernel’s Spanning Tree Protocol, or STP.
A public PoC has also been released, showing how the flaw can be triggered on a vulnerable system
A Linux bridge connects multiple network interfaces so they can communicate as if they were part of the same physical network.
It works much like a network switch and is commonly used in virtual machines, Docker and LXC containers, Kubernetes systems, cloud servers, network appliances, and software-defined networks.
-20260806150259.webp "Linux bridge STP use-after-free bug")
A bridge may use STP to prevent network loops.
Without it, the same traffic could keep going around the network, making communication slower or even stopping it completely.STP controls which bridge ports are allowed to forward data so this doesn’t happen.
The flaw only appeared under a specific set of conditions.
Kernel-based STP had to be enabled on a Linux bridge.The bridge then had to stay in a DOWN state, meaning the interface still existed but wasn’t active.One of its ports also had to move into the LEARNING state, where it collects MAC address information before sending normal traffic.
While this was happening, the kernel could start an STPOrganizations using Linux servers, containers, Kubernetes, or cloud infrastructure should verify that affected kernels are patched and review exposed systems for related risks. Regular vulnerability assessments, infrastructure testing, threat intelligence monitoring, and incident response planning can also help identify similar flaws early and reduce the impact of future attacks. timer without checking whether the bridge was actually UP.
Linux could therefore set a timer even when the interface was turned off.
STP uses several timers to manage network changes, including:
• hello_timer
• tcn_timer
• topology_change_timer
• Timers connected to individual bridge ports
These timers are stored in a kernel structure called struct net_bridge, which belongs to the bridge device’s memory.
As long as the bridge remains in place, the timers and the memory they reference are valid.
Problems occur when the bridge is deleted while one of those timers is still active.
The bridge data is removed from memory, but the timer may remain in the kernel’s timer queue.When its scheduled time arrives, the kernel runs the callback, which tries to access bridge information that has already been freed.
This is known as a use-after-free vulnerability.
Programs reserve memory to store information and release it when that information is no longer needed.
A use-after-free bug happens when software later tries to access the released memory.The original data may no longer be there, and another process or kernel object may already be using the same space.
The result could be:
• A system crash
• Memory corruption
• Unstable behavior
• A denial-of-service condition
• More serious exploitation in some cases
In this Linux flaw, the freed object came from the kmalloc-cg-8k slab cache, a kernel memory area used to store objects of similar sizes.
Linux already had a safe cleanup process for normal shutdowns.
When a bridge changes from UP to DOWN, the kernel follows its regular shutdown path and reaches a function called br_stp_disable_bridge().
That function cancels the STP timers with del_timer_sync().
It waits until the timer has fully stopped and confirms that no callback is still running on another CPU.Using the earlier analogy, Linux turns off every clock before removing the control room.
Direct bridge deletion did not follow the same cleanup path.
Linux handles bridge removal through br_dev_delete(), and the vulnerable version of that function did not perform the same STP timer cleanup.
The issue was more likely to appear when the bridge was already DOWN.
During device removal, Linux could skip its normal stop function because the interface appeared to be turned off already.From the kernel’s perspective, there was no obvious reason to stop it again, even though an STP timer could still be running in the background.
Linux then freed the bridge device and its related data while the timer remained connected to a per-CPU timer queue.
The kernel later processed that timer in softirq context and attempted to access the deleted bridge structure, creating the use-after-free condition.
-20260806150847.webp "Linux bridge STP use-after-free bug")
A system crash is the easiest outcome to reproduce.
A vulnerable machine could freeze, restart, or become unavailable, creating a denial-of-service risk.
Under the right conditions, researchers believe the impact could be greater.
After the bridge memory is released, an attacker may try to place controlled information in the same location.If that memory is reused before the timer runs, the callback could read the attacker’s data instead of the original bridge structure.
A skilled attacker might then attempt to modify a sensitive value, such as a function pointer.
A function pointer tells the kernel which code it should execute.Gaining control of that value could allow the old timer to direct the kernel toward an unintended location.
Organizations using Linux servers, containers, Kubernetes, or cloud infrastructure should verify that affected kernels are patched and review exposed systems for related risks. Regular vulnerability assessments, infrastructure testing, threat intelligence monitoring, and incident response planning can also help identify similar flaws early and reduce the impact of future attacks.
