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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 30 Jun 2014 20:54:34 +0200 From: Hannes Frederic Sowa <hannes@...essinduktion.org> To: Jesper Dangaard Brouer <brouer@...hat.com>, "Eric W. Biederman" <ebiederm@...ssion.com> Cc: Cong Wang <xiyou.wangcong@...il.com>, David Miller <davem@...emloft.net>, Linux Kernel Network Developers <netdev@...r.kernel.org>, Patrick McHardy <kaber@...sh.net>, Stephen Hemminger <stephen@...workplumber.org>, Cong Wang <cwang@...pensource.com>, Stefan Bader <stefan.bader@...onical.com>, stephane.graber@...onical.com, chris.j.arges@...onical.com, Serge Hallyn <serge.hallyn@...onical.com> Subject: Re: [Patch net-next] net: make neigh tables per netns Hi, On Mon, Jun 30, 2014, at 20:15, Jesper Dangaard Brouer wrote: > > On Fri, 27 Jun 2014 22:12:52 -0700 ebiederm@...ssion.com (Eric W. > Biederman) wrote: > > Cong Wang <xiyou.wangcong@...il.com> writes: > > > On Thu, Jun 26, 2014 at 3:44 PM, David Miller <davem@...emloft.net> wrote: > > >> > [...] > > > > > > Hmm, I did overlook the potential DOS problem. But hold on, isn't > > > IP fragments have the same problem? The fragment queues are per > > > netns, and the thresh is per netns as well, we will eventually have > > > memory pressure as well. > > > > Interesting. It does look like ip fragments are susceptible that way. > > For IP fragments we have per netns mem-limit and LRU-list, but all > netns share the same hash table, which have its own DoS potential. > > And argh! - we have a hardcoded INETFRAGS_MAXDEPTH=128, which can be > used for (slow) DoS of IP frags if enough netns are created. > > https://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/tree/net/ipv4/inet_fragment.c#n344 > > Introduced by commit 5a3da1fe9 ("inet: limit length of fragment queue > hash table bucket lists"). Sure, but we need that, otherwise even a single netns can get exploited up to a remotely triggered lockup of the box - e.g. https://gist.github.com/hannes/5116331 - on some smaller machines. INETFRAGS_MAXDEPTH is a property of the hashtable and walking a chain with more than 128 elements is just crazy. Also, for me making this user configurable doesn't seem to provide a benefit. Sure, it does introduce some kind of unfairness between the namespaces, but so does all code which overcommits shared resources. Bye, Hannes -- 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
Powered by blists - more mailing lists