CVE-2026-98122: vxlan: mdb: Fix use-after-free in vxlan_mdb_remote_src_del()
In the Linux kernel, the following vulnerability has been resolved:
vxlan: mdb: Fix use-after-free in vxlanmdbremotesrcdel()
vxlanmdbisvalidsource(), which validates MDBEATTRSOURCE and every MDBEATTRSRCLIST 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 vxlanmdbentrykey, so if MDBEATTRSOURCE 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 MDBEATTRSOURCE is not equivalent, as the key is then left with a zero address family.
vxlanmdbremotesrcdel() removes the forwarding entry of a source before freeing the source entry:
vxlanmdbremotesrcfwddel(vxlan, group, remote, &ent->addr); vxlanmdbremotesrcentrydel(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 hlistdel() reads ->pprev and ->next out of it and writes through them.
Adding the (, G) entry with NLMFREPLACE and no source list marks the all-zeros source for deletion and reaches this from the sweep at the end of vxlanmdbremotesrcsreplace().
BUG: KASAN: slab-use-after-free in vxlanmdbadd+0x1cd/0xd70 Read of size 8 at addr ffff888102852500 by task poc/84 vxlanmdbadd+0x1cd/0xd70 vxlanmdbadd+0xc0/0x140 rtnlmdbadd+0x157/0x2a0 rtnetlinkrcvmsg+0x207/0x5a0 Allocated by task 84: kmalloccachenoprof+0x153/0x360 vxlanmdbremotesrcsadd+0x2eb/0x440 vxlanmdbadd+0x803/0xd70 Freed by task 84: kfree+0x14c/0x3b0 vxlanmdbremotedel+0x129/0x1a0 vxlanmdbdel+0x4f/0xe0 vxlanmdbremotesrcfwddel.isra.0+0x162/0x1b0 vxlanmdbadd+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 vxlanmdbisvalidsource(), 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>
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
Reject the all-zeros address in vxlan_mdb_is_valid_source(), validating MDBE_ATTR_SOURCE and every source-list member.
Event History
Frequently Asked Questions
What configuration triggers the unsafe entry aliasing?
The condition requires MDBE_ATTR_SOURCE to contain the all-zeros address and the source list to also contain the all-zeros address. This makes the derived (S, G) key byte-identical to the existing (*, G) key.
How can an affected system be identified?
Inspect VXLAN MDB configuration for a (*, G) entry where MDBE_ATTR_SOURCE is explicitly present with an all-zeros address and the associated source list includes that same all-zeros address. Omitting MDBE_ATTR_SOURCE does not create the same key because the address family remains zero.
What happens when the problematic entry is removed?
Removal can delete the remote associated with the entry that owns the source entry, rather than a separate derived entry. The source entry is then freed before a subsequent operation accesses it, resulting in a use-after-free.