CVE-2026-93250: vxlan: mdb: Fix use-after-free in vxlan_mdb_flush()
In the Linux kernel, the following vulnerability has been resolved:
vxlan: mdb: Fix use-after-free in vxlanmdbflush()
vxlanmdbflush() iterates over the MDB entries using hlistforeachentrysafe(), 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:
vxlanmdbremotesflush() -> vxlanmdbremotedel() -> vxlanmdbremotesrcsdel() -> vxlanmdbremotesrcdel() -> vxlanmdbremotesrcfwddel() -> vxlanmdbdel() -> vxlanmdbentryput()
Such an entry can be located after the (, G) entry in the list, as vxlanmdbentryget() 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 NLMFREPLACE, as the addition of the source otherwise fails with -EEXIST. The (S, G) entry is then the entry saved by hlistforeachentrysafe() and it is freed while the (, G) entry is processed. The next iteration calls hlistdel() on it again, writing LISTPOISON1 to LISTPOISON2 [1].
Besides device deletion, the flush is also reachable from RTMDELMDB with NLMFBULK.
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 vxlanmdbentryput.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: vxlanmdbentryput.part.0+0x328/0x588 vxlanmdbflush+0x1d8/0x25c vxlanmdbfini+0x8c/0x100 vxlanuninit+0x1c/0x7c unregisternetdevicemanynotify+0x954/0xd4c rtnldellink+0x210/0x530 rtnetlinkrcvmsg+0x434/0x4d0 netlinkrcvskb+0xc4/0x204 rtnetlinkrcv+0x18/0x24 netlinkunicast+0x4b8/0x548 netlinksendmsg+0x29c/0x560 syssendmsg+0x390/0x3ec syssendmsg+0x114/0x188 syssendmsg+0xf0/0x178 arm64syssendmsg+0x48/0x60 invokesyscall.constprop.0+0x58/0x180 el0svccommon.constprop.0+0x74/0x140 doel0svc+0x30/0x40 el0svc+0x38/0x98 el0t64synchandler+0xa0/0xe4 el0t64sync+0x198/0x19c
Affected Software
Event History
Frequently Asked Questions
What VXLAN MDB state is required for the unsafe condition to occur?
The MDB list must contain a source-specific (S,G) entry followed by a wildcard-source (*,G) entry whose remote flush removes the source-specific entry. The described ordering can result from adding the (S,G) entry first and then adding the (*,G) entry with NLM_F_REPLACE.
Why does processing the wildcard-source entry cause a problem?
Flushing remotes from the (*,G) entry can remove related (S,G) entries when they no longer have remotes. If one of those entries was saved as the next item by the safe-list iterator, it is freed during processing and then handled again on the next iteration.