[PATCH net] vxlan: reject appending a remote to a nexthop fdb entry

vxlan_fdb_update_existing() guards nexthop entries against nhid
replacement (nhid && !f->nh) and against nhid-carrying NLM_F_APPEND,
but the plain NLM_F_APPEND branch for multicast/zero MACs never
checks f->nh: vxlan_fdb_append() happily links a remote onto an
entry that is backed by a nexthop group.

This breaks the "nexthop entries have no remote list" invariant: the
xmit path consults f->nh while dump/notify/delete walk the remotes
list.  Concretely, the appended remote is invisible in fdb dumps,
yet "bridge fdb del ... dst <ip>" removes it, and once the last
remote is gone the whole nexthop entry is destroyed, silently
dropping a forwarding binding the user never asked to remove.

Commit 98fc57d167446 ("vxlan: reject dynamic fdb entries that
reference a nexthop id") closed the sibling nh/state mixing vector;
this is the same invariant violation through the opposite door.

Reject NLM_F_APPEND on nexthop-backed entries.

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 <redacted>
---
 drivers/net/vxlan/vxlan_core.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/drivers/net/vxlan/vxlan_core.c b/drivers/net/vxlan/vxlan_core.c
index 3390e341d1e58..aff450ff6aea7 100644
--- a/drivers/net/vxlan/vxlan_core.c
+++ b/drivers/net/vxlan/vxlan_core.c

@@ -1038,6 +1038,11 @@ static int vxlan_fdb_update_existing(struct vxlan_dev *vxlan,
 	if ((flags & NLM_F_APPEND) &&
 	    (is_multicast_ether_addr(f->key.eth_addr) ||
 	     is_zero_ether_addr(f->key.eth_addr))) {
+		if (rcu_access_pointer(f->nh)) {
+			NL_SET_ERR_MSG(extack,
+				       "Cannot append a remote to a nexthop fdb");
+			return -EOPNOTSUPP;
+		}
 		rc = vxlan_fdb_append(f, ip, port, vni, ifindex, &rd);
 
 		if (rc < 0)

-- 
2.43.7