CVE-2026-80838

What it actually does

Use-after-free in vxlan receive learning path: filtered FDB flush unlinks the final remote in vxlan_fdb_dst_destroy before vxlan_flush destroys the parent entry, allowing first_remote_rcu to return a pointer to an empty list head that can be read or written by concurrent RCU readers.

Why it matters to the business

Linux systems using VXLAN overlays risk kernel crashes, memory corruption, or remote code execution in the network stack, potentially disrupting virtual networking, container connectivity, or cloud workloads until patches are applied.

How an attack unfolds

An attacker with the ability to trigger or observe FDB operations sends traffic that populates a non-nexthop FDB entry with a single remote, then induces a filtered bulk flush matching that remote; the resulting window lets an RCU reader dereference the freed or invalid remote structure during packet receive learning.

How to fix it

Upgrade the Linux kernel to a version containing the fix that keeps the last remote linked during FDB flush and delegates destruction to vxlan_fdb_destroy; rebuild and reboot affected hosts; where immediate patching is impossible, restrict unprivileged netlink access and limit VXLAN interface creation to trusted contexts.

How to confirm the fix worked

Confirm the running kernel contains the commit that alters vxlan_fdb_dst_destroy and vxlan_flush to preserve the final remote; inspect vxlan module source for the updated list handling logic; test by exercising FDB flush paths under RCU stress and verify no invalid remote pointers are observed.

Typical attack path

1. Populate a vxlan FDB entry with exactly one remote via legitimate or crafted traffic
2. Trigger a filtered FDB flush (via netlink or internal call) that matches the sole remote
3. Race with an RCU reader in the receive path that calls first_remote_rcu on the now-empty list head
4. Read or write through the invalid remote pointer to corrupt kernel memory or trigger a crash

How to detect it

Review kernel logs for oops or warnings referencing vxlan_fdb_dst_destroy, first_remote_rcu, or list_entry_rcu near FDB flush operations; correlate with netlink messages that perform bulk FDB deletes; examine packet receive paths for unexpected memory accesses in the vxlan module.

What your security team should do

• Prioritize kernel upgrades on all systems exposing VXLAN interfaces
• Monitor upstream stable and distribution kernels for the referenced fix
• Reduce attack surface by restricting CAP_NET_ADMIN and VXLAN configuration to minimal necessary processes
• Include VXLAN FDB flush paths in kernel fuzzing and RCU race testing