KernelScan.io

HIGH Introduced in 6.4

vxlan MDB Source UAF

CVE-2026-98122

CVSS 7.8 / 10.0 NVD

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

KernelScan AI8.8HIGH

01

In the Linux kernel, the following vulnerability has been resolved: vxlan: mdb: Fix use-after-free in vxlan_mdb_remote_src_del() vxlan_mdb_is_valid_source(), which validates MDBE_ATTR_SOURCE and every MDBE_ATTR_SRC_LIST member, accepts the all-zeros address. A source list is only accepted on a (*, G) entry, whose source is the all-zeros address, and for each member of the list an (S, G) entry is derived from it by substituting the source. Entries are keyed by a plain memcmp() of struct vxlan_mdb_entry_key, so if MDBE_ATTR_SOURCE is present and holds the all-zeros address and the source list holds it as well, the derived (S, G) key is byte-identical to the (*, G) key and resolves to the same entry. Omitting MDBE_ATTR_SOURCE is not equivalent, as the key is then left with a zero address family. vxlan_mdb_remote_src_del() removes the forwarding entry of a source before freeing the source entry: vxlan_mdb_remote_src_fwd_del(vxlan, group, remote, &ent->addr); vxlan_mdb_remote_src_entry_del(ent); With the keys aliased, the first call deletes the remote of the entry that owns 'ent' instead of a separate (S, G) entry, and frees 'ent'. The second call then runs on the freed entry, and its hlist_del() reads ->pprev and ->next out of it and writes through them. Adding the (*, G) entry with NLM_F_REPLACE and no source list marks the all-zeros source for deletion and reaches this from the sweep at the end of vxlan_mdb_remote_srcs_replace(). BUG: KASAN: slab-use-after-free in __vxlan_mdb_add+0x1cd/0xd70 Read of size 8 at addr ffff888102852500 by task poc/84 __vxlan_mdb_add+0x1cd/0xd70 vxlan_mdb_add+0xc0/0x140 rtnl_mdb_add+0x157/0x2a0 rtnetlink_rcv_msg+0x207/0x5a0 Allocated by task 84: __kmalloc_cache_noprof+0x153/0x360 vxlan_mdb_remote_srcs_add+0x2eb/0x440 __vxlan_mdb_add+0x803/0xd70 Freed by task 84: kfree+0x14c/0x3b0 vxlan_mdb_remote_del+0x129/0x1a0 __vxlan_mdb_del+0x4f/0xe0 vxlan_mdb_remote_src_fwd_del.isra.0+0x162/0x1b0 __vxlan_mdb_add+0x1c5/0xd70 The MDB operations are netns-scoped, so an unprivileged user can perform them in a new user and network namespace. Reject the all-zeros address in vxlan_mdb_is_valid_source(), which covers both call sites. A (*, G) entry is expressed by omitting the source, so nothing legitimate is refused. Discovered by XBOW, triaged by Baul Lee <baul.lee@xbow.com>

02

Engine v0.6.0

Risk summary

An unprivileged local user can trigger a use-after-free in the VXLAN multicast database subsystem by sending crafted netlink MDB messages from within a user namespace. The freed memory is accessed for linked-list removal, enabling kernel memory corruption that can lead to privilege escalation or a kernel crash. Any system allowing unprivileged user namespaces is exposed.

Affecteddrivers/net/vxlan/vxlan_mdb.c (vxlan mdb)

Vulnerability analysis

The VXLAN multicast database control path accepts an all-zeros IP address as a valid MDB source. When this address appears both as the explicit source of a (*, G) entry and as a member of its source list, the derived (S, G) entry key becomes byte-identical to the (*, G) key, so a deletion routine ends up freeing the owning entry and then operating on that freed memory to remove it from a linked list. The fix rejects all-zeros source addresses during validation, since (*, G) entries are correctly expressed by omitting the source attribute entirely. The vulnerable path is reached through netlink MDB operations, which are network-namespace-scoped, so an unprivileged local user can trigger it by creating a user and network namespace without any host-level privileges.

03

BranchIntroducedFixed inPatch commit
6.126.46.12.111e12c903fd13c
6.186.46.18.5374e2a56c8220
6.66.46.6.158069d5527bb0f
7.26.47.2.771203a41d6fa
mainline6.47.34aa61c88b4e2
cip/6.126.46.12.111-cip32e12c903fd13c

04

State of the newest release of each Civil Infrastructure Platform SLTS tree, from CIP's own fix records.

CIP treeState
cip/6.12Fixed in 6.12.111-cip32