CVE-2026-97615 in Linux
Summary
by MITRE • 09/25/2026
In the Linux kernel, the following vulnerability has been resolved:
net: bridge: use option bits for CFM/MRP frame handlers
CFM and MRP register a global br_frame_type whose hlist_node is linked into the per-bridge frame_type_list when the first MEP/MRP instance is created. Enabling the protocol on multiple bridges therefore inserts the same node into multiple lists. Unregistering it on one bridge then corrupts list state belonging to another.
These handlers can only be installed once per bridge, and they are uncommon. Track their per-bridge enable state with net_bridge option bits, which already live on the Rx hot cache line, and dispatch the matching handler directly from the receive path. Check both bits together first as an unlikely case.
Remove the generic frame_type_list and br_frame_type helpers, which have had no other users since CFM and MRP were added. That shrinks struct net_bridge by 8 bytes and drops the list walk from the fast path. When neither protocol is compiled in, BR_CFM_MRP_OPTS is 0 and the compiler prunes the branch.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/25/2026
The vulnerability identified involves a critical logic error within the Linux kernel networking subsystem, specifically affecting the bridge implementation when handling Connectivity Fault Management (CFM) and Media Redundancy Protocol (MRP) frames. The core issue stems from how these protocol handlers register their frame type callbacks with the network bridge infrastructure. Historically, CFM and MRP registered a global frame handler structure whose node was linked into a per-bridge list of frame types upon the creation of the first Management Entity Point or MRP instance on that specific bridge interface. This design assumes exclusive ownership of the registration mechanism but fails to account for scenarios where multiple bridges exist within the same kernel environment. When CFM or MRP is enabled on more than one network bridge, the same global hlist_node object is inserted into the frame_type_list of each respective bridge simultaneously.
This concurrent insertion creates a severe memory corruption vulnerability because standard linked list operations are not designed to handle a single node being part of multiple distinct lists without proper isolation mechanisms. The structural integrity of these lists relies on unique pointers for previous and next elements within any given context. By sharing the same node across different bridges, modifications made during registration or unregistration in one bridge's context inadvertently alter the pointer values expected by another bridge's list structure. Consequently, when a frame handler is unregistered from one specific bridge, it corrupts the internal state of the linked lists belonging to other active bridges that share the same global node reference. This corruption can lead to kernel panics, data integrity issues, or potential privilege escalation vectors if an attacker can trigger these registration and unregistration cycles through network manipulation or local configuration changes.
From a security architecture perspective, this flaw aligns with CWE-824, which describes access of a resource after it has been freed or used inappropriately due to improper state management, although more specifically it reflects issues related to concurrent list corruption often categorized under CWE-362 for race conditions involving shared resources without proper synchronization. In the context of the MITRE ATT&CK framework, this vulnerability could potentially be leveraged by an attacker with local access or network control over bridge configurations to cause a Denial of Service against the host system by inducing kernel instability through crafted configuration changes that trigger the list corruption during unregistration phases. The impact is significant as it compromises the stability and reliability of virtualized networking environments where multiple bridges are commonly deployed, such as in container orchestration platforms or cloud infrastructure hypervisors.
The resolution implemented addresses this architectural flaw by abandoning the generic frame_type_list mechanism for CFM and MRP handlers entirely. Instead, the fix introduces per-bridge enable state tracking using existing net_bridge option bits that reside on the receive path hot cache line. This approach eliminates the need for dynamic list manipulation during runtime operations involving these specific protocols. The dispatch logic is now integrated directly into the packet receive path, where both protocol options are checked together in a single conditional branch before invoking the appropriate handler if enabled. Since CFM and MRP usage is uncommon compared to standard bridging traffic, this change also provides performance benefits by removing unnecessary list traversal overhead from the fast path of network processing.
Furthermore, the cleanup removes the now-redundant generic frame_type_list infrastructure and associated helper functions that were exclusively used by these two protocols. This refactoring results in a reduction of struct net_bridge size by eight bytes, contributing to better memory efficiency. The compiler is also able to optimize away the conditional checks entirely when neither CFM nor MRP is compiled into the kernel configuration, ensuring zero performance overhead for systems not utilizing these specific redundancy or fault management features. For system administrators and developers, mitigating this risk involves updating the Linux kernel to a version where this patch has been applied. In environments running older kernels without immediate access to updates, restricting the ability of unprivileged users to create or destroy network bridges can serve as a temporary operational mitigation to prevent triggering the list corruption logic until the software stack is patched.