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
| ||
|
Date: Thu, 4 Aug 2016 17:15:22 +0900 From: Toshiaki Makita <makita.toshiaki@....ntt.co.jp> To: Roopa Prabhu <roopa@...ulusnetworks.com> Cc: "David S. Miller" <davem@...emloft.net>, Stephen Hemminger <stephen@...workplumber.org>, netdev@...r.kernel.org, bridge@...ts.linux-foundation.org, Nikolay Aleksandrov <nikolay@...ulusnetworks.com> Subject: Re: [PATCH net] bridge: Fix problems around fdb entries pointing to the bridge device On 2016/08/04 16:24, Roopa Prabhu wrote: > On 8/3/16, 7:11 PM, Toshiaki Makita wrote: >> Adding fdb entries pointing to the bridge device uses fdb_insert(), >> which lacks various checks and does not respect added_by_user flag. >> >> As a result, some inconsistent behavior can happen: >> * Adding temporary entries succeeds but results in permanent entries. > > IIRC this is not specific to fdb entries on the bridge device. all temp > fdb entries via iproute2 result in permanent entries. thats why 'dynamic' > was added. Sorry for confusing you, I meant "temp" (i.e., "static") of bridge fdb command. "temp", "dynamic" and "use" should not result in "permanent". >> * Same goes for "dynamic" and "use". > This patch seems to not allow dynamic and use entries > on the bridge device. I don't see a strong use-case to > allow them, but any reason you want to add the restriction now ? Because dynamic fdb entries pointing the bridge device cannot be created. So it is prohibited. I cannot find other appropriate behavior about this. Or are you suggesting local entries with aging supported or something like that? >> * Changing mac address of the bridge device causes deletion of >> user-added entries. > unless I am missing something, this does not seem to be related to the > external fdb entry on the bridge device. Yes this is related to manually-added fdb entries on the bridge device. When manual addition of fdb pointing the bridge device was introduced, we should have set added_by_user on adding the entry and modify br_fdb_change_mac_address() to respect the flag, but both were not done. > >> * Replacing existing entries looks successful from userspace but actually >> not, regardless of NLM_F_EXCL flag. > curious about this one. I will try it, but if you have an example that > will help. Before: # bridge fdb add 12:34:56:78:90:ab dev enp3s0 master # bridge fdb add 12:34:56:78:90:ab dev br0; echo $? 0 # bridge fdb show ... 12:34:56:78:90:ab dev enp3s0 master br0 permanent # bridge fdb replace 12:34:56:78:90:ab dev br0; echo $? 0 # bridge fdb show ... 12:34:56:78:90:ab dev enp3s0 master br0 permanent After: # bridge fdb add 12:34:56:78:90:ab dev enp3s0 master # bridge fdb add 12:34:56:78:90:ab dev br0; echo $? RTNETLINK answers: File exists 255 # bridge fdb replace 12:34:56:78:90:ab dev br0; echo $? 0 # bridge fdb show ... 12:34:56:78:90:ab dev br0 master br0 permanent -- Toshiaki Makita
Powered by blists - more mailing lists