CVE-2026-80838: vxlan: keep the last remote linked during FDB flush
In the Linux kernel, the following vulnerability has been resolved:
vxlan: keep the last remote linked during FDB flush
A non-nexthop FDB entry is expected to have at least one remote while it remains reachable through the FDB hash table. A filtered bulk flush violates this invariant when every remote matches: It unlinks the last remote in vxlanfdbdstdestroy() and only afterwards tells vxlanflush() to destroy the parent FDB entry.
An RCU reader can find the parent during this interval. firstremotercu() then applies listentryrcu() to the empty list head, producing an invalid remote pointer that the receive learning path can read from and write to.
When a matching remote is the sole remaining remote, leave it linked and ask the caller to destroy the entire FDB entry. vxlanfdbdestroy() keeps the remote attached while sending the deletion notification and removing the parent from the lookup structures.
Affected Software
Event History
Frequently Asked Questions
What conditions are required for this issue to occur?
The system must use VXLAN with a non-nexthop FDB entry, and a filtered bulk FDB flush must match every remote associated with that entry. The race occurs when the matching remote is the sole remaining remote while an RCU reader can still look up the parent FDB entry.
What concurrent activity makes the flaw reachable?
An RCU reader must find the FDB parent in the hash table during the interval after its last remote has been unlinked but before the parent entry is removed. The receive learning path can then read from and write through an invalid remote pointer.
How can I determine whether a system is exposed?
Review whether the host uses Linux VXLAN and performs filtered bulk flushes of VXLAN FDB entries. Exposure specifically depends on flushes that remove all remotes from a non-nexthop FDB entry while the entry remains temporarily reachable.