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:
<pre>
vxlan_mdb_remote_src_fwd_del(vxlan, group, remote, &ent->addr);
vxlan_mdb_remote_src_entry_del(ent);
</pre>
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
CVSS Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS Score: 7.8
AV:L - The malformed input is an RTM_NEWMDB rtnetlink message sent from a local socket (rtnl_mdb_add -> vxlan_mdb_add -> __vxlan_mdb_add -> vxlan_mdb_remote_srcs_replace -> vxlan_mdb_remote_src_del); no packet received from the network reaches the MDB control path.
AC:L - It is deterministic, with no race: add a (*, G) entry with MDBE_ATTR_SOURCE 0.0.0.0 and 0.0.0.0 in MDBE_ATTR_SRC_LIST, then re-add it with NLM_F_REPLACE and no source list. The attacker creates every piece of the required state.
PR:L - The only check is netlink_net_capable(CAP_NET_ADMIN) in rtnetlink_rcv_msg, which is namespace-scoped. An unprivileged user can get it with unshare -Urn, create their own vxlan device and send RTM_NEWMDB to it.
UI:N - The attacker's own netlink messages, on a vxlan device they created in their own namespace, trigger the bug; no other user has to do anything.
S:U - Corrupting kernel heap memory gives kernel-level impact within the same security authority, which is ordinary local privilege escalation with no VM or hardware boundary crossed.
C:H - A heap spray can reclaim the freed vxlan_mdb_src_entry before vxlan_mdb_remote_src_entry_del reads it, so the attacker controls the pointers the kernel then uses. This is a slab use-after-free that can be built into a kernel memory disclosure.
I:H - hlist_del() in vxlan_mdb_remote_src_entry_del reads ->next and ->pprev from the freed entry and writes through them. Once the slot is reclaimed with controlled data, that is an attacker-directed pointer write (an unlink write primitive).
A:H - Unlinking a freed hlist node corrupts kernel memory; KASAN reports it in __vxlan_mdb_add, and without KASAN the corrupted list pointers can oops or panic the kernel. Any user who can open a user namespace can trigger it repeatedly.
| Attack Vector |
Local |
Scope |
Unchanged |
| Attack Complexity |
Low |
Confidentiality Impact |
High |
| Privileges Required |
Low |
Integrity Impact |
High |
| User Interaction |
None |
Availability Impact |
High |
AV:L - The malformed input is an RTM_NEWMDB rtnetlink message sent from a local socket (rtnl_mdb_add -> vxlan_mdb_add -> __vxlan_mdb_add -> vxlan_mdb_remote_srcs_replace -> vxlan_mdb_remote_src_del); no packet received from the network reaches the MDB control path.
AC:L - It is deterministic, with no race: add a (*, G) entry with MDBE_ATTR_SOURCE 0.0.0.0 and 0.0.0.0 in MDBE_ATTR_SRC_LIST, then re-add it with NLM_F_REPLACE and no source list. The attacker creates every piece of the required state.
PR:L - The only check is netlink_net_capable(CAP_NET_ADMIN) in rtnetlink_rcv_msg, which is namespace-scoped. An unprivileged user can get it with unshare -Urn, create their own vxlan device and send RTM_NEWMDB to it.
UI:N - The attacker's own netlink messages, on a vxlan device they created in their own namespace, trigger the bug; no other user has to do anything.
S:U - Corrupting kernel heap memory gives kernel-level impact within the same security authority, which is ordinary local privilege escalation with no VM or hardware boundary crossed.
C:H - A heap spray can reclaim the freed vxlan_mdb_src_entry before vxlan_mdb_remote_src_entry_del reads it, so the attacker controls the pointers the kernel then uses. This is a slab use-after-free that can be built into a kernel memory disclosure.
I:H - hlist_del() in vxlan_mdb_remote_src_entry_del reads ->next and ->pprev from the freed entry and writes through them. Once the slot is reclaimed with controlled data, that is an attacker-directed pointer write (an unlink write primitive).
A:H - Unlinking a freed hlist node corrupts kernel memory; KASAN reports it in __vxlan_mdb_add, and without KASAN the corrupted list pointers can oops or panic the kernel. Any user who can open a user namespace can trigger it repeatedly.
CVSS 3.1