On 11/15/2017 11:31 PM, Nikolay Aleksandrov wrote: > On 15/11/17 21:27, Sarah Newman wrote: >> Current memory and CPU usage for managing bridge fdb entries is unbounded. >> Add a parameter max_fdb_count, controlled from sysfs, which places an upper >> limit on the number of entries. Defaults to 1024. >> >> When max_fdb_count is met or exceeded, whether traffic is sent out a >> given port should depend on its flooding behavior. >> >> This may instead be mitigated by filtering mac address entries in the >> PREROUTING chain of the ebtables nat table, but this is only practical >> when mac addresses are known in advance. >> > > One alternative solution: if limit is the only requirement it could be done > in user-space (even with a shell script) looking at fdb notifications and > if you reach some limit then remove the learning flag from ports, later if > enough expire turn it back on. In fact you can make any policy and if you > catch an offending port - you can disable only its learning flag and leave the > rest.
Leaving such a trivial DOS in the kernel doesn't seem like a good idea to me, but I suppose it hasn't bothered anyone else up to now except this person back in 2013: https://www.keypressure.com/blog/linux-bridge-port-security/ I note that anyone who would run up against a too-low limit on the maximum number of fdb entries would also be savvy enough to fix it in a matter of minutes. They could also default the limit to U32_MAX in their particular distribution if it was a configuration option. At the moment there is not even a single log message if the problem doesn't result in memory exhaustion. --Sarah
