CVE-2026-97615: net: bridge: use option bits for CFM/MRP frame handlers
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 brframetype whose hlistnode is linked into the per-bridge frametypelist 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 netbridge 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 frametypelist and brframetype helpers, which have had no other users since CFM and MRP were added. That shrinks struct netbridge by 8 bytes and drops the list walk from the fast path. When neither protocol is compiled in, BRCFMMRPOPTS is 0 and the compiler prunes the branch.
Affected Software
Event History
Frequently Asked Questions
Which deployments are exposed to the list corruption?
The issue affects Linux bridge deployments where CFM or MRP is enabled on multiple bridges. The handlers are installed at most once per bridge, but the same global handler node was linked into each bridge's list.
What event triggers the corruption?
Corruption occurs when the shared CFM or MRP handler is unregistered on one bridge after it has been registered on multiple bridges. Unregistering from one bridge can corrupt frame-handler list state associated with another bridge.