From: Nikolay Aleksandrov <razor@blackwall.org>
To: Baul Lee <baul.lee@xbow.com>, Andrew Lunn <andrew+netdev@lunn.ch>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>
Cc: Ido Schimmel <idosch@nvidia.com>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
federico.kirschbaum@xbow.com
Subject: Re: [PATCH net v2] vxlan: mdb: Fix use-after-free in vxlan_mdb_remote_src_del()
Date: Sun, 30 Aug 2026 11:35:02 +0300 [thread overview]
Message-ID: <2ef6bf41-8626-40ce-8ba8-82dbd3f0c30e@blackwall.org> (raw)
In-Reply-To: <c985ef2a-3e0d-48fc-9e21-33501bb92cf3@blackwall.org>
On 26/08/2026 20:40, Nikolay Aleksandrov wrote:
> On 26/08/2026 20:36, Baul Lee wrote:
>> 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>
>>
>> Fixes: a3a48de5eade ("vxlan: mdb: Add MDB control path support")
>> Signed-off-by: Baul Lee <baul.lee@xbow.com>
>> ---
>
> You should wait 24 hours before posting another version
Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org>
next prev parent reply other threads:[~2026-08-30 8:35 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-26 17:36 [PATCH net v2] vxlan: mdb: Fix use-after-free in vxlan_mdb_remote_src_del() Baul Lee
2026-08-26 17:40 ` Nikolay Aleksandrov
2026-08-30 8:35 ` Nikolay Aleksandrov [this message]
2026-08-27 9:17 ` Ido Schimmel
2026-08-30 21:40 ` patchwork-bot+netdevbpf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2ef6bf41-8626-40ce-8ba8-82dbd3f0c30e@blackwall.org \
--to=razor@blackwall.org \
--cc=andrew+netdev@lunn.ch \
--cc=baul.lee@xbow.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=federico.kirschbaum@xbow.com \
--cc=idosch@nvidia.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.