CVE-2026-93250 in Linux
Summary
by MITRE • 09/24/2026
In the Linux kernel, the following vulnerability has been resolved:
vxlan: mdb: Fix use-after-free in vxlan_mdb_flush()
vxlan_mdb_flush() iterates over the MDB entries using hlist_for_each_entry_safe(), which only tolerates the removal of the current entry. Contrary to the comment above the loop, the removal of an entry can trigger the removal of another entry.
Flushing the remotes of a (*, G) entry also removes the (S, G) entries that were created for its source list, once they are left without remotes:
vxlan_mdb_remotes_flush() -> vxlan_mdb_remote_del() -> vxlan_mdb_remote_srcs_del() -> vxlan_mdb_remote_src_del() -> vxlan_mdb_remote_src_fwd_del() -> __vxlan_mdb_del() -> vxlan_mdb_entry_put()
Such an entry can be located after the (*, G) entry in the list, as vxlan_mdb_entry_get() returns an existing entry without moving it to the head of the list. This order is obtained by adding the (S, G) entry before the (*, G) entry, the latter with NLM_F_REPLACE, as the addition of the source otherwise fails with -EEXIST. The (S, G) entry is then the entry saved by hlist_for_each_entry_safe() and it is freed while the (*, G) entry is processed. The next iteration calls hlist_del() on it again, writing LIST_POISON1 to LIST_POISON2 [1].
Besides device deletion, the flush is also reachable from RTM_DELMDB with NLM_F_BULK.
Fix by re-reading the next entry after the remotes were flushed. The current entry cannot be removed by this flush, as source lists can only be configured on (*, G) entries and the removed entries are (S, G) entries. It is therefore still linked and its next pointer reflects the removals.
[1]
BUG: KASAN: wild-memory-access in vxlan_mdb_entry_put.part.0+0x328/0x588 Write of size 8 at addr dead000000000122 by task ip/327
CPU: 3 UID: 1000 PID: 327 Comm: ip Not tainted 7.2.0-rc7 #2 PREEMPT Call trace: vxlan_mdb_entry_put.part.0+0x328/0x588 vxlan_mdb_flush+0x1d8/0x25c vxlan_mdb_fini+0x8c/0x100 vxlan_uninit+0x1c/0x7c unregister_netdevice_many_notify+0x954/0xd4c rtnl_dellink+0x210/0x530 rtnetlink_rcv_msg+0x434/0x4d0 netlink_rcv_skb+0xc4/0x204 rtnetlink_rcv+0x18/0x24 netlink_unicast+0x4b8/0x548 netlink_sendmsg+0x29c/0x560 ____sys_sendmsg+0x390/0x3ec ___sys_sendmsg+0x114/0x188 __sys_sendmsg+0xf0/0x178 __arm64_sys_sendmsg+0x48/0x60 invoke_syscall.constprop.0+0x58/0x180 el0_svc_common.constprop.0+0x74/0x140 do_el0_svc+0x30/0x40 el0_svc+0x38/0x98 el0t_64_sync_handler+0xa0/0xe4 el0t_64_sync+0x198/0x19c
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/24/2026
The Linux kernel VXLAN implementation contains a critical use-after-free vulnerability within the multicast database flushing logic, specifically in the vxlan_mdb_flush function. This flaw arises from an incorrect assumption regarding list iteration safety during dynamic memory management operations. The original code utilizes hlist_for_each_entry_safe to iterate over Multicast Database entries, relying on this macro to safely handle the removal of the current entry being processed. However, the underlying implementation fails to account for cascading deletions triggered by side effects within the loop body. When flushing remote addresses associated with a (, G) multicast group entry, the kernel invokes vxlan_mdb_remotes_flush which subsequently calls vxlan_mdb_remote_del and proceeds through a chain of deletion functions including vxlan_mdb_remote_srcs_del and vxlan_mdb_remote_src_fwd_del. This sequence ultimately leads to __vxlan_mdb_del being called on source-specific (S, G) entries that are linked in the same list as the (, G) entry currently under iteration.
The root cause of this vulnerability lies in the specific ordering and linkage behavior of VXLAN multicast group entries. When a source is added to an existing group using NLM_F_REPLACE, the kernel creates or updates the (S, G) entry before finalizing the (, G) entry structure due to existence checks that would otherwise fail with -EEXIST errors if processed in reverse order. Consequently, the (S, G) entries often appear after the (, G) entry in the internal hash list. Because vxlan_mdb_entry_get does not move accessed entries to the head of the list, the iteration pointer saved by hlist_for_each_entry_safe may point to an (S, G) entry that is subsequently deleted as a side effect of processing a preceding or concurrent (*, G) entry flush operation. When the loop attempts to proceed to the next element using the now-stale pointer from the freed memory block, it results in a use-after-free condition where kernel code writes to invalid memory addresses, specifically writing LIST_POISON1 to LIST_POISON2 as indicated by KASAN reports showing wild-memory-access errors at dead000000000122.
This vulnerability is reachable through multiple attack vectors within the network stack. It can be triggered during device deletion operations when VXLAN interfaces are unregistered, but it is also exploitable via netlink messages using RTM_DELMDB with NLM_F_BULK flags. An attacker or misconfigured application could trigger bulk multicast database flushes that exploit this race condition between list iteration and recursive entry removal. The operational impact includes kernel memory corruption which can lead to system crashes, denial of service through panic conditions, or potentially arbitrary code execution if the corrupted pointers are manipulated in specific ways during subsequent memory allocations. The severity is heightened by the fact that VXLAN is commonly used in virtualized environments where network configuration changes occur frequently, increasing the likelihood of encountering this edge case under normal operational loads.
The remediation for this issue involves modifying the iteration logic to re-read the next entry pointer after any remote flushing operations have completed within the loop body. Since source-specific lists are only configured on (*, G) entries and the removed entries are strictly (S, G) types that appear later in the list, the current entry being processed remains valid and linked even if subsequent entries are deleted. By refreshing the next pointer after vxlan_mdb_remotes_flush executes, the iterator maintains a consistent view of the remaining list structure without dereferencing freed memory. This fix aligns with standard practices for safe traversal of dynamic data structures in kernel space where elements may be removed by side effects during iteration.
From a security classification perspective, this vulnerability maps to CWE-416 Use After Free and CWE-362 Concurrent Execution Using Shared Resource with Improper Synchronization due to the unsafe list manipulation context. In terms of attack patterns, it relates to ATT&CK technique T1059 Command and Scripting Interpreter via netlink interfaces which allow remote configuration changes that can trigger local kernel exploitation paths if input validation or state management is flawed. Mitigation strategies include applying the upstream Linux kernel patch immediately upon availability for affected distributions. For environments where immediate patching is not feasible, restricting access to RTM_DELMDB operations and limiting bulk multicast group modifications can reduce exposure. Additionally, enabling Kernel Address Sanitizer (KASAN) in development or staging environments helps detect such memory safety violations early before they manifest as exploitable vulnerabilities in production systems.