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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox