From: Ido Schimmel <idosch@nvidia.com>
To: Henry Martin <bsdhenrymartin@gmail.com>
Cc: "David S . Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>,
Eric Dumazet <edumazet@kernel.org>,
Paolo Abeni <pabeni@redhat.com>, Andrew Lunn <andrew@lunn.ch>,
Simon Horman <horms@kernel.org>,
Kuniyuki Iwashima <kuniyu@google.com>,
Petr Machata <petrm@nvidia.com>,
Ferruh Yigit <ferruh.yigit@amd.com>,
Antoine Tenart <atenart@redhat.com>,
Ilya Maximets <i.maximets@ovn.org>,
Seungwon Bae <qotmddnjs@gmail.com>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
stable@vger.kernel.org
Subject: Re: [PATCH net v2] vxlan: reject adding a remote to a nexthop fdb entry
Date: Wed, 21 Oct 2026 13:26:14 +0300 [thread overview]
Message-ID: <20261021102614.GA3351287@shredder> (raw)
In-Reply-To: <20261020034531.1420194-1-bsdhenrymartin@gmail.com>
On Tue, Oct 20, 2026 at 11:45:31AM +0800, Henry Martin wrote:
> FDB entries backed by a nexthop group must not carry a remote
> destination list. vxlan_fdb_update_existing() currently appends a
> remote via vxlan_fdb_append() on an NLM_F_APPEND request with a
> multicast or zero MAC even when the entry is backed by a nexthop,
> breaking that invariant through three different callers:
>
> - "bridge fdb append" with a dst on a nexthop entry;
> - "ip link set dev vx0 type vxlan remote <ip>" (vxlan_changelink());
> - "bridge vni add/change ... group <mcast>" on a vnifilter device
> (vxlan_update_default_fdb_entry()).
>
> All three reach the append block with nhid == 0 and a PERMANENT
> state, so they pass the earlier nexthop checks.
>
> Reject the combination at the top of vxlan_fdb_update_existing(),
> next to the existing nexthop guards, so a refused request has no
> side effects: placing the check in the append block instead would
> return -EOPNOTSUPP only after the entry state and flags have been
> rewritten, skipping both the notification pass and the err_notify
> rollback.
>
> Note the resulting behavior change for the two rtnetlink callers:
> operations that previously succeeded while silently attaching an
> unused remote to a nexthop entry now fail with extack
> "Cannot add a remote to a nexthop fdb entry".
>
> This issue was discovered by Tencent CodeBuddy Security.
>
> Cc: stable@vger.kernel.org
> Fixes: 1274e1cc4226 ("vxlan: ecmp support for mac fdb entries")
> Signed-off-by: Henry Martin <bsdhenrymartin@gmail.com>
I agree that it doesn't make sense to append a remote to an FDB entry
that points to a nexthop, but what are the consequences of allowing it?
Does this patch fix a crash / memory leak? If so, the commit message
should describe it. Otherwise, this looks like net-next material
(currently closed).
Also, please add a test case in fib_nexthops.sh, in a similar fashion to
commit 98fc57d16744 ("vxlan: reject dynamic fdb entries that reference a
nexthop id").
next prev parent reply other threads:[~2026-10-21 10:26 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-20 3:45 [PATCH net v2] vxlan: reject adding a remote to a nexthop fdb entry Henry Martin
2026-10-20 3:48 ` netdev-bot+sinfo
2026-10-21 10:26 ` Ido Schimmel [this message]
2026-10-27 10:45 ` henry martin
2026-10-22 6:47 ` netdev-bot+sashiko
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=20261021102614.GA3351287@shredder \
--to=idosch@nvidia.com \
--cc=andrew@lunn.ch \
--cc=atenart@redhat.com \
--cc=bsdhenrymartin@gmail.com \
--cc=davem@davemloft.net \
--cc=edumazet@kernel.org \
--cc=ferruh.yigit@amd.com \
--cc=horms@kernel.org \
--cc=i.maximets@ovn.org \
--cc=kuba@kernel.org \
--cc=kuniyu@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=petrm@nvidia.com \
--cc=qotmddnjs@gmail.com \
--cc=stable@vger.kernel.org \
/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.