CVE-2026-68116 is a semantic vulnerability in the VXLAN multicast database (MDB) state machine, not a memory corruption bug. The flaw lives in the rollback logic for vxlan_mdb_remote_srcs_add(), which performs a two-phase replacement: marking existing sources for deletion, then adding new ones. When the addition phase fails partway through, the error handler unconditionally tears down the entire source list. This works correctly for pure "add" operations (where every entry on the list is newly allocated) but destroys pre-existing sources during a "replace" operation, leaving deletion marks uncleared on entries that should survive.
The fix introduces VXLAN_SGRP_F_NEW, a flag marking entries created during the current operation. The error path then surgically removes only uncommitted additions while restoring deletion marks on survivors — textbook transactional semantics retrofitted onto existing state. The vulnerability exists because the original helper was designed for a single operational context (add), and when the replace path reused it, the rollback assumptions went unexamined.
The traffic manipulation consequences are serious. A partially rolled-back EXCLUDE filter will forward multicast traffic it should block; a partially rolled-back INCLUDE filter will drop traffic it should forward. The EXCLUDE failure is worse — it creates an unintended multicast replication path bypassing group membership controls. Multicast streams in production often carry high-value data (video distribution, financial market data, control plane telemetry), so the impact extends beyond generic packet loss into competitive harm or infrastructure exposure.
Triggering this reliably for exploitation is uncertain. ENOMEM during source allocation is the obvious trigger, but kernel __GFP_NOFAIL behavior makes purely probabilistic failure difficult. The more concerning vector is the persistent state corruption: the corrupted multicast forwarding table doesn't self-heal, creating a durable exploit condition that can be triggered from an initially privileged position and exploited at leisure — fundamentally different from transient timing vulnerabilities.
This exact semantic error has appeared before. CVE-2021-45469 in bridge MDB and CVE-2022-41674 in veth followed the identical arc: a helper designed for one operational mode acquired a second caller with incompatible rollback requirements, and the error path preserved the original assumptions. Each was patched with flag-based entry marking — the same solution used here. The repeated discovery of this pattern across subsystems across years reveals a structural blind spot in kernel code review: reviewers examine what code does on success; what it does on failure is someone else's problem. Geneve, GRE, and bareudp paths almost certainly contain similar rollback assumptions in stateful replace operations — the same API design pressure that produced this vulnerability is systemic across kernel network virtualization code.
Check whether your VXLAN MDB configurations use (*, G) entries with source lists, and audit any custom or vendor-specific code that calls vxlan_mdb_remote_srcs_add(). The vulnerability is patched in upstream kernels, but the organizational pattern that produced it — fixes treated as isolated correctness bugs rather than signals propagating laterally — remains unremediated.