KernelScan.io

HIGH Introduced in 5.11

bridge FrameType UAF

CVE-2026-97615

CVSS 7.3 / 10.0 KernelScan AI

CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H

01

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.

02

Engine v0.6.0

Risk summary

An unprivileged local user who can obtain CAP_NET_ADMIN in a user namespace can corrupt a bridge's internal frame-handler list by enabling CFM or MRP on multiple bridges. Each protocol uses its own global list node that gets inserted into every bridge where the protocol is enabled. This can cause a kernel soft lockup or a use-after-free write to freed memory when a bridge is deleted. The issue affects any system running the bridge module with CFM or MRP support compiled in and is reachable from containers and user namespaces.

Affectednet/bridge/br_input.c (bridge)

Vulnerability analysis

CFM and MRP protocols each use a single global frame-handler node that gets linked into a bridge's private list when the protocol is first enabled on that bridge. Enabling the same protocol on a second bridge re-inserts the same global node into a different list, corrupting the first list's linkage. Subsequent unregister operations then modify the wrong bridge's list state, which can produce a self-referencing list that loops forever in the packet receive path, or a write to freed memory when a bridge is deleted while its list head is still referenced by the shared node. The fix replaces the shared list-node mechanism with per-bridge option bits that the receive path checks directly before dispatching to the appropriate handler, eliminating the shared state entirely. The vulnerability is reachable by any local user who can obtain network-administrator capability in a user namespace, including unprivileged container workloads, and requires the bridge module with CFM or MRP support compiled in.

03

BranchIntroducedFixed inPatch commit
6.125.116.12.112be5ead655241
6.185.116.18.53994fd705ca49
6.65.116.6.160260f99b355a4
7.25.117.2.742e033c8f30f
mainline5.117.37a49e6b16f36
cip/6.125.116.12.112-cip33be5ead655241

04

State of the newest release of each Civil Infrastructure Platform SLTS tree, from CIP's own fix records.

CIP treeState
cip/6.12Fixed in 6.12.112-cip33
cip/6.1Affected — no CIP fix yet (latest 6.1.189-cip61)
cip/6.1-rtAffected — no CIP fix yet (latest 6.1.189-cip61-rt32)