netdev - Re: [Patch net-next] net: make neigh tables per netns

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:	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