linux-kernel - Re: nf_conntrack: falling back to vmalloc.

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] [day] [month] [year] [list]

Message-ID: <20150723104526.GA13915@salvia>
Date:	Thu, 23 Jul 2015 12:45:26 +0200
From:	Pablo Neira Ayuso <pablo@...filter.org>
To:	Florian Westphal <fw@...len.de>
Cc:	Toralf Förster <toralf.foerster@....de>,
	netfilter-devel@...r.kernel.org,
	Linux Kernel <linux-kernel@...r.kernel.org>, kaber@...sh.net,
	Marcelo Leitner <mleitner@...hat.com>
Subject: Re: nf_conntrack: falling back to vmalloc.

On Fri, Jul 17, 2015 at 12:10:09PM +0200, Florian Westphal wrote:
> Toralf Förster <toralf.foerster@....de> wrote:
> > I do run a server with a 64 bit hardened Gentoo Linux (kernel currently 4.0.8).
> > Around 12th of July it started to spew those messages into kern.log :
> > 
> > /var/log/kern.log:Jul 12 15:26:07 tor-relay kernel: [538360.650490] nf_conntrack: falling back to vmalloc.
> > /var/log/kern.log:Jul 12 15:26:07 tor-relay kernel: [538360.650615] nf_conntrack: falling back to vmalloc.
> > /var/log/kern.log:Jul 12 15:26:08 tor-relay kernel: [538361.673649] nf_conntrack: falling back to vmalloc.
> > /var/log/kern.log:Jul 12 15:26:08 tor-relay kernel: [538361.673786] nf_conntrack: falling back to vmalloc.
> > 
> > I read https://bugzilla.openvz.org/show_bug.cgi?id=3092 but a reboot did not help.
> > I got 1-2 thousends of those lines per day.
> 
> Most likely result of 88eab472ec21f01d3e36ff ("netfilter: conntrack:
> adjust nf_conntrack_buckets default value".

I think we can get rid of that warning, it will most likely shown
every time after that patch.

[...]
> Pablo, Patrick -- any idea on how to stop conntrack from becoming active
> in a newly created netns automatically without breaking anything?
>
> With upcoming per netns hooks, we might be able to delay registering
> conntrack, defrag etc.  until after a -m conntrack rule has been added.
> Dou you think that could work?
>
> For nft we could create an expression to configure conntrack explicitly
> (inverse NOTRACK).
> 
> [ obviously we can also add that for xtables but that would break
>   setups if we suddently move to "you must ask for conntrack via
>   ruleset" model. ]

With netns in place, I think it's now clear that we need that this is
configurable at ruleset level that we've been discussing for a while.
But users will have to request this new behaviour to avoid breaking
existing setups...

View attachment "x.patch" of type "text/x-diff" (604 bytes)