From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 2DBD54090D DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 3B481408DD DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Nvidia.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HH/HNX/O64uh6//8dN+ZMSiPTY1JIq0z4NEtphMDd/4=; b=uil2jMhQGHbMi1jOW7jqSQRgCv2mWWCKMnsIKfEQL7KPfG9oK6ZY0u+25W/yo0wVOUYdVzopjoxx1ybN//ccmeD4EfTx8ZRU9b+owN7VZZs7t6Bs/CKEGaBe/mG87eIjyxTJAiUC6KhcrVFCyo956ZCXAuE3pI9oO4M9k8rK5/RQsVcD8iWYfhtwkBgSF9sjFz5NlhIIilcAq9vUewQhAXkfMwdkTKnTWHdkM4Qjaf5EzNwkF77CQ8Li72Q/tX2VfqY7ip3CVqv9KksR+sPL8p3AMTffOgVAnGCjWXa19sl74EQ/2/XnL/7HdiNQfGYMPK+b8qyNqbSvjL8kCXUwUQ== From: Ido Schimmel Date: Mon, 13 Mar 2023 16:53:42 +0200 Message-Id: <20230313145349.3557231-5-idosch@nvidia.com> In-Reply-To: <20230313145349.3557231-1-idosch@nvidia.com> References: <20230313145349.3557231-1-idosch@nvidia.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain MIME-Version: 1.0 Subject: [Bridge] [PATCH net-next 04/11] rtnetlink: bridge: mcast: Relax group address validation in common code List-Id: Linux Ethernet Bridging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: netdev@vger.kernel.org, bridge@lists.linux-foundation.org Cc: petrm@nvidia.com, mlxsw@nvidia.com, razor@blackwall.org, Ido Schimmel , edumazet@google.com, roopa@nvidia.com, kuba@kernel.org, pabeni@redhat.com, davem@davemloft.net In the upcoming VXLAN MDB implementation, the 0.0.0.0 and :: MDB entries will act as catchall entries for unregistered IP multicast traffic in a similar fashion to the 00:00:00:00:00:00 VXLAN FDB entry that is used to transmit BUM traffic. In deployments where inter-subnet multicast forwarding is used, not all the VTEPs in a tenant domain are members in all the broadcast domains. It is therefore advantageous to transmit BULL (broadcast, unknown unicast and link-local multicast) and unregistered IP multicast traffic on different tunnels. If the same tunnel was used, a VTEP only interested in IP multicast traffic would also pull all the BULL traffic and drop it as it is not a member in the originating broadcast domain [1]. Prepare for this change by allowing the 0.0.0.0 group address in the common rtnetlink MDB code and forbid it in the bridge driver. A similar change is not needed for IPv6 because the common code only validates that the group address is not the all-nodes address. [1] https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-irb-mcast#section-2.6 Signed-off-by: Ido Schimmel --- net/bridge/br_mdb.c | 6 ++++++ net/core/rtnetlink.c | 5 +++-- 2 files changed, 9 insertions(+), 2 deletions(-) diff --git a/net/bridge/br_mdb.c b/net/bridge/br_mdb.c index 76636c61db21..7305f5f8215c 100644 --- a/net/bridge/br_mdb.c +++ b/net/bridge/br_mdb.c @@ -1246,6 +1246,12 @@ static int br_mdb_config_init(struct br_mdb_config *cfg, struct net_device *dev, } } + if (cfg->entry->addr.proto == htons(ETH_P_IP) && + ipv4_is_zeronet(cfg->entry->addr.u.ip4)) { + NL_SET_ERR_MSG_MOD(extack, "IPv4 entry group address 0.0.0.0 is not allowed"); + return -EINVAL; + } + if (tb[MDBA_SET_ENTRY_ATTRS]) return br_mdb_config_attrs_init(tb[MDBA_SET_ENTRY_ATTRS], cfg, extack); diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c index f347d9fa78c7..b7b1661d0d56 100644 --- a/net/core/rtnetlink.c +++ b/net/core/rtnetlink.c @@ -6152,8 +6152,9 @@ static int rtnl_validate_mdb_entry(const struct nlattr *attr, } if (entry->addr.proto == htons(ETH_P_IP)) { - if (!ipv4_is_multicast(entry->addr.u.ip4)) { - NL_SET_ERR_MSG(extack, "IPv4 entry group address is not multicast"); + if (!ipv4_is_multicast(entry->addr.u.ip4) && + !ipv4_is_zeronet(entry->addr.u.ip4)) { + NL_SET_ERR_MSG(extack, "IPv4 entry group address is not multicast or 0.0.0.0"); return -EINVAL; } if (ipv4_is_local_multicast(entry->addr.u.ip4)) { -- 2.37.3