CVE-2026-80838 in Linux
Summary
by MITRE • 09/04/2026
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 vxlan_fdb_dst_destroy() and only afterwards tells vxlan_flush() to destroy the parent FDB entry.
An RCU reader can find the parent during this interval. first_remote_rcu() then applies list_entry_rcu() 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. vxlan_fdb_destroy() keeps the remote attached while sending the deletion notification and removing the parent from the lookup structures.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/04/2026
The vulnerability identified in the Linux kernel's Virtual Extensible LAN (VXLAN) implementation centers on a race condition within the Forwarding Database (FDB) flush mechanism, specifically affecting how remote next-hop entries are managed during bulk deletion operations. VXLAN is a network virtualization technology that encapsulates Layer 2 Ethernet frames within UDP packets to create overlay networks across IP-based infrastructures. The integrity of these overlays relies heavily on the accurate maintenance of FDB tables, which map MAC addresses to specific tunnel endpoints or remotes. In this scenario, the flaw occurs when a filtered bulk flush operation is executed against an FDB entry that has only one remaining remote next-hop. Under normal operational expectations, any non-nexthop FDB entry must maintain at least one valid remote reference while it remains accessible through the FDB hash table to ensure data plane continuity and prevent packet loss or misdirection.
The technical root cause lies in the ordering of operations within the vxlan_fdb_dst_destroy function relative to the parent FDB entry destruction logic. When a bulk flush identifies that all remotes associated with an FDB entry match specific filter criteria, it proceeds to unlink the last remaining remote via vxlan_fdb_dst_destroy before instructing vxlan_flush to destroy the parent FDB entry itself. This sequence creates a critical time window where the parent FDB structure is still present in the lookup tables and potentially accessible by concurrent readers, yet its associated remote list has already been emptied or invalidated. The kernel uses Read-Copy-Update (RCU) mechanisms for safe concurrent access to data structures, allowing multiple readers to proceed without locking while writers update the data safely. However, this implementation fails to account for RCU readers that may probe the FDB entry during the brief interval between unlinking the remote and destroying the parent structure.
During this vulnerable window, an RCU reader executing in a receive learning path can locate the parent FDB entry through standard hash table lookups. The function first_remote_rcu is then invoked to retrieve the initial remote from the list associated with that FDB entry. Because the last remote has already been unlinked but not yet fully destroyed or removed from all contexts, this operation applies list_entry_rcu to an empty list head. This results in the generation of a pointer to invalid memory or a struct containing garbage data rather than a valid network destination structure. The receive path subsequently attempts to read from and write to this invalid remote pointer, leading to undefined behavior that can manifest as kernel panics, memory corruption, or privilege escalation if an attacker can trigger specific conditions to exploit the corrupted state.
The operational impact of this vulnerability is significant for systems relying on VXLAN overlays, particularly in cloud-native environments where dynamic FDB updates are frequent and high-volume bulk operations are common. An unprivileged local user who has access to network namespaces or container interfaces could potentially craft packets or trigger specific administrative commands that induce the flawed flush sequence. By forcing a race condition between the remote unlinking and parent destruction phases, an attacker might cause a denial of service through kernel crashes or, in more complex exploitation scenarios involving memory corruption primitives derived from the invalid pointer dereference, achieve arbitrary code execution with kernel privileges. This undermines the stability and security boundaries of virtualized network environments that depend on consistent state management for overlay connectivity.
To mitigate this vulnerability, the Linux kernel developers have implemented a fix that alters the lifecycle management of FDB entries during bulk flushes. The updated logic ensures that when a matching remote is the sole remaining remote associated with an entry, it remains linked within the data structure rather than being immediately unlinked. Instead, the system defers the complete removal until after the deletion notification has been sent and the parent entry has been safely removed from all lookup structures via vxlan_fdb_destroy. This adjustment preserves the invariant that a reachable FDB entry must have at least one valid remote reference throughout its existence in the hash table, thereby eliminating the window where RCU readers could encounter an empty list head or invalid pointer state.
From a classification perspective, this vulnerability aligns with CWE-362, which describes concurrent execution error and race conditions involving shared resources without proper synchronization. The specific mechanism of accessing freed or invalidated memory structures through improper lifecycle management also relates to CWE-416, Use After Free, as the RCU reader accesses data that is in a transitional state effectively equivalent to being freed from the perspective of structural integrity. In terms of attack vectors and techniques, this flaw can be leveraged within the MITRE ATT&CK framework under T1059, Command and Scripting Interpreter, if used for initial access via container escape or network manipulation tools, but more critically it falls under T1213, Data from Information Repositories, as an attacker might exploit the memory corruption to read sensitive kernel data. Furthermore, the potential for privilege escalation places this within the scope of T1068, Exploitation for Privilege Escalation.
System administrators and security engineers should prioritize applying the latest stable Linux kernel updates that include this VXLAN FDB fix across all hosts participating in overlay networks. Given the complexity of race conditions, relying solely on network segmentation or firewall rules is insufficient to prevent exploitation if local access exists within a compromised container or virtual machine environment. Continuous monitoring for unusual kernel log messages related to RCU stalls or null pointer dereferences can provide early indicators of attempted exploitation. Additionally, adopting defense-in-depth strategies such as restricting unprivileged user access to network namespace manipulation tools and enabling strict kernel hardening parameters like CONFIG_STRICT_DEVMEM can reduce the attack surface available to potential adversaries seeking to leverage this flaw for deeper system compromise.