Description

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

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.8",
  "pubDate": "2026-09-24T16:17:21.187Z",
  "pubdate": "2026-09-24T16:17:21.187Z",
  "executiveSummary": "A use-after-free vulnerability exists in the Linux kernel's VXLAN Multicast Database (MDB) subsystem, specifically within the vxlan_mdb_flush() function.\nThe flaw originates from an improper use of hlist_for_each_entry_safe() during the removal of MDB entries, failing to account for recursive deletion chains where one MDB entry removal triggers the deletion of another.\nThis vulnerability affects the VXLAN implementation within the Linux kernel and can be triggered via netlink messages (RTM_DELMDB) or during device deletion.\nSuccessful exploitation leads to a wild-memory-access, resulting in a kernel panic or potentially exploitable heap corruption due to the kernel incorrectly attempting to operate on already freed memory structures (LIST_POISON1/2).\nAn attacker with the ability to configure or influence VXLAN MDB states, typically requiring CAP_NET_ADMIN privileges, can trigger this vulnerability to cause a local Denial of Service (DoS) or potentially execute arbitrary code depending on kernel heap layout.",
  "technicalDetails": "The vulnerability resides in vxlan_mdb_flush(), which is responsible for flushing MDB entries. The implementation utilizes the hlist_for_each_entry_safe macro to iterate through and remove list elements. While hlist_for_each_entry_safe is designed to protect against the removal of the current element during iteration, it fails to anticipate the complex, multi-layered deletion process inherent in VXLAN MDB management.\nThe root cause is that flushing (*, G) entries triggers a cascading delete sequence via 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(). In scenarios where an (S, G) entry is positioned after a (*, G) entry in the same list, the destruction of the (*, G) entry's associated remotes inadvertently frees the (S, G) entry.\nBecause the (S, G) entry was the next element pre-cached by the hlist_for_each_entry_safe iterator, the subsequent loop iteration attempts to process a pointer that has already been deallocated and poisoned by the kernel memory allocator (KASAN detects this as a wild-memory-access). This causes the kernel to attempt to modify a freed object, leading to illegal memory writes (LIST_POISON1 into LIST_POISON2).\nThe specific sequence leading to this state occurs when an (S, G) entry is inserted prior to the (*, G) entry—a condition permitted when the (*, G) entry is added with NLM_F_REPLACE to bypass -EEXIST errors during source configuration. Because vxlan_mdb_entry_get() does not reorder the list, the vulnerable ordering is preserved in memory.\nThe attack vector is via the netlink interface. An authenticated user with sufficient privileges (CAP_NET_ADMIN) can send RTM_DELMDB messages with the NLM_F_BULK flag, forcing the kernel to iterate over and flush MDB entries in a way that triggers the cascading delete. Additionally, triggering a device deletion (e.g., via unregister_netdevice) reaches the same flawed flush path.\nThe impact is a kernel crash (panic) due to the illegal memory access. In sophisticated attack scenarios, if the attacker can control the heap allocation pattern, the use-after-free might be weaponized to modify sensitive kernel structures, though the primary observed impact is DoS."
}