search for: br_fdb_change_mac_address

.... All changes to fdb_n_entries are under br->hash_lock, which means we do not need additional locking. The call paths are (? denotes that br->hash_lock is taken around the next call): - fdb_delete <-+- fdb_delete_local <-+- br_fdb_changeaddr ? | +- br_fdb_change_mac_address ? | +- br_fdb_delete_by_port ? +- br_fdb_find_delete_local ? +- fdb_add_local <-+- br_fdb_changeaddr ? | +- br_fdb_change_mac_address ? | +- br_fdb_add_local ?...

...ntries are under br->hash_lock, which means we do > not need additional locking. The call paths are (? denotes that > br->hash_lock is taken around the next call): > > - fdb_delete <-+- fdb_delete_local <-+- br_fdb_changeaddr ? > | +- br_fdb_change_mac_address ? > | +- br_fdb_delete_by_port ? > +- br_fdb_find_delete_local ? > +- fdb_add_local <-+- br_fdb_changeaddr ? > | +- br_fdb_change_mac_address ? > |...

.... All changes to fdb_n_entries are under br->hash_lock, which means we do not need additional locking. The call paths are (? denotes that br->hash_lock is taken around the next call): - fdb_delete <-+- fdb_delete_local <-+- br_fdb_changeaddr ? | +- br_fdb_change_mac_address ? | +- br_fdb_delete_by_port ? +- br_fdb_find_delete_local ? +- fdb_add_local <-+- br_fdb_changeaddr ? | +- br_fdb_change_mac_address ? | +- br_fdb_add_local ?...

...810c7dc9>] SyS_delete_module+0x199/0x2b0 [ 563.468259] [<ffffffff814e0922>] system_call_fastpath+0x16/0x1b [ 570.377958] Bridge firewalling registered ------------------------- cut here --------------------------- The reason is that if the bridge dev''s address is changed, the br_fdb_change_mac_address() will add new address in fdb, but when the bridge was removed, the address entry in the fdb did not free, the bridge_fdb_cache still has objects when destroy the cache, Fix this by flushing the bridge address entry when removing the bridge. Signed-off-by: Ding Tianhong <dingtianhong@huawei.com...

Introduce a limit on the amount of learned FDB entries on a bridge, configured by netlink with a build time default on bridge creation in the kernel config. For backwards compatibility the kernel config default is disabling the limit (0). Without any limit a malicious actor may OOM a kernel by spamming packets with changing MAC addresses on their bridge port, so allow the bridge creator to limit

...: Wei Yongjun <yongjun_wei at trendmicro.com.cn> --- net/bridge/br_fdb.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/net/bridge/br_fdb.c b/net/bridge/br_fdb.c index b0812c9..48fe761 100644 --- a/net/bridge/br_fdb.c +++ b/net/bridge/br_fdb.c @@ -161,9 +161,7 @@ void br_fdb_change_mac_address(struct net_bridge *br, const u8 *newaddr) if (!pv) return; - for (vid = find_next_bit(pv->vlan_bitmap, BR_VLAN_BITMAP_LEN, vid); - vid < BR_VLAN_BITMAP_LEN; - vid = find_next_bit(pv->vlan_bitmap, BR_VLAN_BITMAP_LEN, vid+1)) { + for_each_set_bit_from(vid, pv->vlan_bitmap...

...810c7dc9>] SyS_delete_module+0x199/0x2b0 [ 563.468259] [<ffffffff814e0922>] system_call_fastpath+0x16/0x1b [ 570.377958] Bridge firewalling registered ------------------------- cut here --------------------------- The reason is that if the bridge dev''s address is changed, the br_fdb_change_mac_address() will add new address in fdb, but when the bridge was removed, the address entry in the fdb did not free, the bridge_fdb_cache still has objects when destroy the cache, Fix this by flushing the bridge address entry when removing the bridge. Signed-off-by: Ding Tianhong <dingtianhong@huawei.com...

The second part of my patch series to fix the handling of addr_assign_type for random MAC addresses. This contains the trival changes from random_ether_addr() to new eth_hw_addr_random() and code to reset the state to NET_ADDR_PERM as soon as the MAC get changed via .ndo_set_mac_address where eth_mac_addr wasn't used. Danny Kukawka (2): net: replace random_ether_addr() with

The second part of my patch series to fix the handling of addr_assign_type for random MAC addresses. This contains the trival changes from random_ether_addr() to new eth_hw_addr_random() and code to reset the state to NET_ADDR_PERM as soon as the MAC get changed via .ndo_set_mac_address where eth_mac_addr wasn't used. Danny Kukawka (2): net: replace random_ether_addr() with

The second part of my patch series to fix the handling of addr_assign_type for random MAC addresses. This contains the trival changes from random_ether_addr() to new eth_hw_addr_random() and code to reset the state to NET_ADDR_PERM as soon as the MAC get changed via .ndo_set_mac_address where eth_mac_addr wasn't used. Danny Kukawka (2): net: replace random_ether_addr() with

The second part of my patch series to fix the handling of addr_assign_type for random MAC addresses. This contains the trival changes from random_ether_addr() to new eth_hw_addr_random() and code to reset the state to NET_ADDR_PERM as soon as the MAC get changed via .ndo_set_mac_address where eth_mac_addr wasn't used. Resend due to send with too long recipients list. Sorry! Thanks to Joe

The second part of my patch series to fix the handling of addr_assign_type for random MAC addresses. This contains the trival changes from random_ether_addr() to new eth_hw_addr_random() and code to reset the state to NET_ADDR_PERM as soon as the MAC get changed via .ndo_set_mac_address where eth_mac_addr wasn't used. Resend due to send with too long recipients list. Sorry! Thanks to Joe

The second part of my patch series to fix the handling of addr_assign_type for random MAC addresses. This contains the trival changes from random_ether_addr() to new eth_hw_addr_random() and code to reset the state to NET_ADDR_PERM as soon as the MAC get changed via .ndo_set_mac_address where eth_mac_addr wasn't used. Resend due to send with too long recipients list. Sorry! Thanks to Joe

Changes since v9: * series re-ordering so make functionality more distinct. Basic vlan filtering is patches 1-4. Support for PVID/untagged vlans is patches 5 and 6. VLAN support for FDB/MDB is patches 7-11. Patch 12 is still additional egress policy. * Slight simplification to code that extracts the VID from skb. Since we now depend on the vlan module, at the time of input skb_tci is

This series of patches provides an ability to add VLANs to the bridge ports. This is similar to what can be found in most switches. The bridge port may have any number of VLANs added to it including vlan 0 priority tagged traffic. When vlans are added to the port, only traffic tagged with particular vlan will forwarded over this port. Additionally, vlan ids are added to FDB entries and become