CVE-2026-98023: vxlan: reject dynamic fdb entries that reference a nexthop id
In the Linux kernel, the following vulnerability has been resolved:
vxlan: reject dynamic fdb entries that reference a nexthop id
The commit cited in the Fixes tag allowed VXLAN FDB entries to point to FDB nexthops so that overlay traffic could be load balanced across multiple VTEPs. Such entries can only be configured from user space, cannot be learned and cannot roam. They only make sense with a user space control plane such as E-VPN where data plane learning is disabled.
Despite that, the VXLAN driver does not currently prevent such entries from being configured with the "dynamic" flag. The per-nexthop FDB list is only protected by the per-device hash lock, which is not sufficient when two VXLAN devices point to the same FDB nexthop and therefore share the list. Aging runs in softirq context without RTNL, so an entry deleted by one device can race with an addition or deletion from the other, leading to list corruption:
listdel corruption. next->prev should be ffff8881069d9548, but was dead000000000122. (next=ffff8881069d9448) WARNING: CPU: 0 PID: 90 at lib/listdebug.c:65 listdelentryvalidorreport+0x1aa/0x210 ... vxlanfdbdestroy+0x5b8/0xad0 vxlancleanup+0x328/0x450 calltimerfn+0x2a/0x1c0 runtimersoftirq+0x18c/0x210 BUG: KASAN: slab-use-after-free in vxlanfdbdestroy
Fix this by rejecting the bogus configuration of dynamic FDB entries that point to FDB nexthops, both when created and when an existing entry is updated. As such, the per-nexthop FDB list is only ever mutated under the RTNL lock. Add test cases to make sure that this does not regress in the future.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
Do not configure dynamic VXLAN FDB entries that reference a nexthop ID; reject such configurations.
Event History
Frequently Asked Questions
Which VXLAN deployments are exposed to this race?
The issue requires VXLAN FDB entries that reference an FDB nexthop ID and are configured with the dynamic flag from user space. It is particularly relevant when two VXLAN devices reference the same FDB nexthop, causing them to share the per-nexthop FDB list.
Can this be triggered through normal VXLAN learning or roaming?
No. Entries that reference FDB nexthops cannot be learned or roam; they can only be configured from user space. These entries are intended for user-space control planes, such as E-VPN deployments with data-plane learning disabled.
What can be done before applying the fix?
Do not configure dynamic VXLAN FDB entries that reference nexthop IDs. Use only configurations that avoid combining the dynamic flag with FDB nexthop references until the corrected kernel is deployed.
How might an affected system manifest the problem?
A race between aging on one VXLAN device and FDB entry addition or deletion on another can corrupt the shared list. Kernel warnings may report list_del corruption and include functions such as vxlan_fdb_destroy and vxlan_cleanup in the stack trace.