Linux Kernel Bridge Vulnerability Lets Attackers Crash Systems, Execute Code

Key Takeaways

• A critical use-after-free vulnerability (CVE-2024-XXXX) has been discovered in the Linux kernel’s bridge subsystem.
• This flaw can lead to system crashes (denial of service) and potentially remote code execution.
• The vulnerability affects Linux kernels prior to commit 2a00517db8de4be7df3d483b215c5544fb30a191, specifically impacting the Spanning Tree Protocol (STP) implementation.
• A public proof-of-concept exists, increasing the urgency for patching.
• A fix is available and administrators should update their kernels and restrict bridge configuration access.

Linux Kernel Bridge Vulnerability Poses System Crash and Code Execution Risk

A significant use-after-free vulnerability has been identified within the Linux kernel’s bridge subsystem, specifically impacting its Spanning Tree Protocol (STP) implementation located in net/bridge. This flaw, for which a public proof-of-concept (PoC) has already been released, could enable attackers to crash affected systems and, under certain conditions, achieve arbitrary code execution.

The core of the issue lies in how the kernel manages STP timers when a bridge network device is deleted. Under specific circumstances, these timers can remain active even after their owning bridge device has been deallocated from memory. This creates a dangerous memory-safety condition within the kmalloc-cg-8k slab cache, leading to the use-after-free vulnerability.

This critical vulnerability manifests when kernel STP is enabled on a bridge that is administratively down, and one of its bridge ports transitions into the LEARNING state. In this scenario, the kernel may arm periodic STP timers without adequately checking the IFF_UP interface flag. These timers are essential for the STP state machine, which prevents Layer 2 network loops by carefully managing bridge-port states and adapting to network topology changes.

Timers such as hello_timer, tcn_timer, topology_change_timer, and various port-specific timers are stored within the struct net_bridge, which itself resides in the private data area of the bridge’s net_device. Consequently, these timers must be properly disarmed and removed before the underlying network device’s memory is released. If they persist in the timer queue after the memory they reference has been freed, the kernel may later attempt to execute a timer callback using a stale, invalid memory address.

Root Cause and Exploitation Potential

According to SSD Disclosure, the underlying cause of this bug is a disparity in cleanup behavior between a standard interface shutdown and a direct bridge deletion. During a typical UP-to-DOWN interface transition, the ndo_stop path triggers br_stp_disable_bridge(), which synchronously cancels all STP timers via del_timer_sync(). This crucial step prevents any pending callbacks from attempting to access already-released bridge data.

However, deleting a bridge through the delink path, which invokes br_dev_delete(), does not initiate the same comprehensive STP cleanup routine. Furthermore, if the interface is already down, the device-unregistration process might bypass ndo_stop entirely. This oversight leaves armed timers still attached to a per-CPU timer base, even though the associated net_device has subsequently been freed. When the kernel’s timer processing routine later attempts to handle these dangling timers within a softirq context, it can dereference freed memory, leading to a system crash.

Security researchers have highlighted that sophisticated attackers could potentially transform this memory corruption bug into a control-flow hijacking primitive. By carefully controlling the reallocation of the freed slab object, they might manipulate the execution flow, elevating the impact beyond a mere denial-of-service scenario to full remote code execution. The public PoC serves as a stark reminder of this vulnerability’s lifecycle and underscores the critical need for prompt remediation, particularly in environments where bridge configuration changes are permitted.

Patch Availability and Mitigation

A patch addressing this vulnerability has been integrated into the Linux kernel via commit 2a00517db8de4be7df3d483b215c5544fb30a191. Any systems running Linux kernels prior to this commit should be considered vulnerable and must be updated without delay using their distribution’s official kernel packages.

What You Should Do

• Update Kernels Immediately: Apply the latest kernel updates provided by your Linux distribution. Ensure your kernel version includes commit 2a00517db8de4be7df3d483b215c5544fb30a191 or later.
• Restrict Bridge Configuration Access: Limit the ability of untrusted users to create, modify, or remove bridge interfaces. Implement strict access controls for network device management.
• Review Workloads: Assess any workloads or applications that rely on kernel STP and bridge configurations to understand potential exposure.
• Monitor System Logs: Keep a close eye on system logs for any unusual activity, kernel panics, or crashes that might indicate exploitation attempts.

Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.