netdev - Re: [Bridge] [PATCH net-next] bridge: vlan: flush the dynamically learned entries on port vlan delete

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]

Date:	Wed, 24 Jun 2015 00:02:33 +0900
From:	Toshiaki Makita <toshiaki.makita1@...il.com>
To:	Nikolay Aleksandrov <nikolay@...ulusnetworks.com>,
	netdev@...r.kernel.org
CC:	vyasevich@...il.com, bridge@...ts.linux-foundation.org,
	davem@...emloft.net
Subject: Re: [Bridge] [PATCH net-next] bridge: vlan: flush the dynamically
 learned entries on port vlan delete

On 15/06/23 (火) 21:28, Nikolay Aleksandrov wrote:
> Add a new argument to br_fdb_delete_by_port which allows to specify a
> vid to match when flushing entries and use it in nbp_vlan_delete() to
> flush the dynamically learned entries of the vlan/port pair when removing
> a vlan from a port. Before this patch only the local mac was being
> removed and the dynamically learned ones were left to expire.
> Note that the do_all argument is still respected and if specified, the
> vid will be ignored.
> 
> Signed-off-by: Nikolay Aleksandrov <nikolay@...ulusnetworks.com>
> ---
> note: There are 2 warnings, the C99 comment was already there and the 81
>        char line is the prototype and I think it looks better this way.
>        One unclear thing is about vid 0, I see that it can be passed to
>        nbp_vlan_(add|delete) although the comment says it shouldn't.

nbp_vlan_add() should not be called with vid 0 because vid 0 of fdb
entries is internally used when vlan_filtering is disabled, and such
entries are exposed to userspace as those without any vlan id.
bridge's vlan_filtering is respecting 802.1Q-2011 spec, which says vid 0
cannot be used as a normal vlan id.
If vlan 0 can be added, it should be a bug.

Toshiaki Makita
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html