netdev - Re: [PATCH net-next 1/2] net: bridge: Install FDB for bridge MAC on VLAN 0

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <2e27010e-5a7b-4dc2-a7dd-703a94d2c4b1@blackwall.org>
Date: Mon, 22 Sep 2025 18:50:36 +0300
From: Nikolay Aleksandrov <razor@...ckwall.org>
To: Petr Machata <petrm@...dia.com>, "David S. Miller" <davem@...emloft.net>,
 Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>,
 Paolo Abeni <pabeni@...hat.com>, Ido Schimmel <idosch@...dia.com>,
 netdev@...r.kernel.org
Cc: Simon Horman <horms@...nel.org>, bridge@...ts.linux-foundation.org,
 mlxsw@...dia.com
Subject: Re: [PATCH net-next 1/2] net: bridge: Install FDB for bridge MAC on
 VLAN 0

On 9/22/25 17:14, Petr Machata wrote:
> Currently, after the bridge is created, the FDB does not hold an FDB entry
> for the bridge MAC on VLAN 0:
> 
>   # ip link add name br up type bridge
>   # ip -br link show dev br
>   br               UNKNOWN        92:19:8c:4e:01:ed <BROADCAST,MULTICAST,UP,LOWER_UP>
>   # bridge fdb show | grep 92:19:8c:4e:01:ed
>   92:19:8c:4e:01:ed dev br vlan 1 master br permanent
> 
> Later when the bridge MAC is changed, or in fact when the address is given
> during netdevice creation, the entry appears:
> 
>   # ip link add name br up address 00:11:22:33:44:55 type bridge
>   # bridge fdb show | grep 00:11:22:33:44:55
>   00:11:22:33:44:55 dev br vlan 1 master br permanent
>   00:11:22:33:44:55 dev br master br permanent
> 
> However when the bridge address is set by the user to the current bridge
> address before the first port is enslaved, none of the address handlers
> gets invoked, because the address is not actually changed. The address is
> however marked as NET_ADDR_SET. Then when a port is enslaved, the address
> is not changed, because it is NET_ADDR_SET. Thus the VLAN 0 entry is not
> added, and it has not been added previously either:
> 
>   # ip link add name br up type bridge
>   # ip -br link show dev br
>   br               UNKNOWN        7e:f0:a8:1a:be:c2 <BROADCAST,MULTICAST,UP,LOWER_UP>
>   # ip link set dev br addr 7e:f0:a8:1a:be:c2
>   # ip link add name v up type veth
>   # ip link set dev v master br
>   # ip -br link show dev br
>   br               UNKNOWN        7e:f0:a8:1a:be:c2 <BROADCAST,MULTICAST,UP,LOWER_UP>
>   # bridge fdb | grep 7e:f0:a8:1a:be:c2
>   7e:f0:a8:1a:be:c2 dev br vlan 1 master br permanent
> 
> Then when the bridge MAC is used as DMAC, and br_handle_frame_finish()
> looks up an FDB entry with VLAN=0, it doesn't find any, and floods the
> traffic instead of passing it up.
> 
> Fix this by simply adding the VLAN 0 FDB entry for the bridge itself always
> on netdevice creation. This also makes the behavior consistent with how
> ports are treated: ports always have an FDB entry for each member VLAN as
> well as VLAN 0.
> 
> Signed-off-by: Petr Machata <petrm@...dia.com>
> Reviewed-by: Ido Schimmel <idosch@...dia.com>
> ---
>   net/bridge/br.c | 5 +++++
>   1 file changed, 5 insertions(+)
> 
> diff --git a/net/bridge/br.c b/net/bridge/br.c
> index 512872a2ef81..c37e52e2f29a 100644
> --- a/net/bridge/br.c
> +++ b/net/bridge/br.c
> @@ -37,6 +37,11 @@ static int br_device_event(struct notifier_block *unused, unsigned long event, v
>   	int err;
>   
>   	if (netif_is_bridge_master(dev)) {
> +		struct net_bridge *br = netdev_priv(dev);
> +
> +		if (event == NETDEV_REGISTER)
> +			br_fdb_change_mac_address(br, dev->dev_addr);
> +
>   		err = br_vlan_bridge_event(dev, event, ptr);
>   		if (err)
>   			return notifier_from_errno(err);

Acked-by: Nikolay Aleksandrov <razor@...ckwall.org>