CVE-2026-68116: VXLAN Failed Replaces Alter Multicast Policy

The NVD published the record on August 10, 2026, using kernel.org’s description and stable-tree fixes. It has not assigned CVSS v4 or v3 severity, a CWE category, or an exploitability assessment. That incompleteness should not obscure the operational result: on affected kernels, a control-plane operation that returns an error can leave multicast forwarding in a materially different state.

For administrators, this is a kernel update issue for systems using VXLAN multicast database entries with

and

configuration—not a blanket VXLAN emergency for every overlay deployment. But where the feature is used to enforce source-aware multicast policy, the defect can turn an error during a

operation into either unwanted forwarding or traffic loss.

A replacement error was not atomic​

The vulnerable logic lives in

, in the path that replaces the source list attached to an existing VXLAN MDB remote entry. MDB, or multicast database, entries tell the bridge and VXLAN code where multicast traffic for a group should go; source-specific entries add a policy decision based on the multicast sender as well as the group.

The intended sequence was straightforward. When replacing a source list, Linux first marked all existing source entries for deletion. It then added the requested new source list, clearing the deletion mark for any existing sources that were also present in the replacement. Once the add pass had succeeded, the kernel removed entries that remained marked.

The defect was in its rollback. If adding the replacement list failed partway through,

deleted every source entry associated with the remote. That cleanup made sense when the same helper was called while creating a new remote entry: in that case, every source on the list had been created during that one operation.

It was wrong during replacement. Existing sources and newly added sources shared the same list, so the failure path removed pre-existing entries along with the incomplete replacement. The command failed, but the forwarding state did not revert to what it was before the command began.

That is the central consequence of CVE-2026-68116: it violates a basic expectation of network configuration tooling. An unsuccessful replace should preserve the old state. On affected kernels, it could instead delete it.

INCLUDE and EXCLUDE failures break in opposite directions​

The impact depends on the MDB entry’s multicast filter mode. The

utility documents that

and

, together with

, apply to wildcard

multicast group entries. In plain terms, an INCLUDE list allows traffic from specified multicast sources, while an EXCLUDE list blocks specified sources.

The kernel advisory spells out the two failure modes. If an EXCLUDE entry loses source records after a failed replace, traffic from sources that should have been blocked can begin forwarding. If an INCLUDE entry loses source records, traffic that should have been allowed can be dropped.

Those are very different incidents in practice:

• An EXCLUDE-policy failure can defeat a deliberate isolation or suppression rule, causing multicast traffic to traverse an overlay where operators expected it to be denied.
• An INCLUDE-policy failure can interrupt applications that rely on tightly scoped multicast delivery, such as clustered services, broadcast-discovery domains, media distribution, or specialized industrial and lab networks.

This is not described as a memory-safety issue, privilege escalation, or kernel crash. It is a forwarding-integrity flaw: a bad outcome from a failed administrative operation can persist in the data plane. That means monitoring only the exit status of an automation job is insufficient. A controller may record a failed update while the network is already forwarding according to neither the old policy nor the requested new policy.

The trigger is also narrower than a normal multicast update. The kernel’s own description says it is reachable from an existing

remote entry. A newly created entry follows a separate case where deleting all provisional sources during rollback is appropriate. The risk is specifically in replacing the source list of an already configured remote.

The patch separates old entries from provisional ones​

The upstream fix introduces a new

flag. Its job is modest but important: distinguish source entries created during the current operation from the source entries that existed before the replacement started.

When a replacement begins, existing entries can still be marked for deletion as before. Newly allocated source entries are then tagged with the new flag. If the operation fails, the kernel deletes only entries marked as new and clears the deletion mark on earlier entries. The old source list therefore survives intact.

The patch also changes flag handling after an individual source is successfully added. Previously, that code cleared all flags on a source entry. The corrected version clears only the delete marker, preserving the new-entry marker until the entire operation has completed. That detail is what lets the higher-level rollback know which entries it is permitted to remove.

There is a second correction in

. If the code found a pre-existing source entry and later failed while adding that source’s forwarding entry, the old error path deleted the looked-up entry anyway. The fix limits that deletion to entries created during the current pass. Without it, the lower-level helper could independently remove a pre-existing source just because programming its forwarding entry failed.

The patch is therefore not merely a broader cleanup loop adjustment. It closes two paths by which an error could turn a lookup of existing policy into deletion of existing policy.

Fixed stable versions are already identified​

The NVD’s kernel.org-supplied affected-version data says the bug was introduced in Linux 6.4. It identifies fixed releases in five maintained lines:

The record also lists five stable-tree commits corresponding to the backports. Distribution kernel package versions may not match the upstream version string, and enterprise vendors regularly backport fixes while retaining an older-looking base version. Administrators should therefore check their vendor’s kernel changelog or security tracker for CVE-2026-68116 rather than conclude that an apparently older release is vulnerable solely from its displayed major and minor version.

Conversely, systems on unpatched custom builds derived from Linux 6.4 or later should not assume that a successful build date protects them. The code change is specific enough to verify: corrected builds carry the

handling in

, preserve old entries on a failed source-list replacement, and prevent a failed forwarding-entry add from deleting a source it did not create.

What operators should check before maintenance windows​

The immediate priority is to identify whether the affected feature is in use. The

interface exposes the relevant configuration: multicast database entries with a

of

or

and a

, associated with a VXLAN device or remote endpoint, deserve review.

Teams that provision these entries through scripts, orchestration platforms, or network controllers should treat failed replacement events as possible state-change events until fixed kernels are deployed. The safest near-term control is to avoid changing source lists on existing VXLAN MDB remote entries where practical, or to validate the resulting MDB state after every attempted replacement.

A useful operational check is to capture the MDB state before and after a change and compare the effective source list rather than trusting only an API response or command exit code. In an INCLUDE configuration, verify that required sources remain present after a rejected update. In an EXCLUDE configuration, verify that blocked sources have not disappeared from the entry.

The absence of a CVSS score is not a reason to defer that work. CVSS would be useful for prioritization, but the technical record already establishes the practical condition: a failed configuration change could leave source-filtered multicast forwarding altered. For VXLAN deployments that use MDB source lists as a policy boundary, the fix restores the behavior operators expected in the first place—failure leaves the working configuration alone.