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:	Sat, 14 May 2016 12:33:09 +0200
From:	Florian Westphal <fw@...len.de>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	Florian Westphal <fw@...len.de>,
	Pablo Neira Ayuso <pablo@...filter.org>,
	netfilter-devel@...r.kernel.org, dale.4d@...il.com,
	netdev@...r.kernel.org
Subject: Re: [PATCH nf V2] netfilter: fix oops in nfqueue during netns error
 unwinding

Eric W. Biederman <ebiederm@...ssion.com> wrote:
> Florian Westphal <fw@...len.de> writes:
> 
> > Eric W. Biederman <ebiederm@...ssion.com> wrote:
> >> Florian could you test and verify this patch fixes your issues?
> >
> > Yes, this seems to work.
> >
> > Pablo, I'm fine with this patch going into -nf/stable but I do not think
> > making the pointers per netns is a desireable option in the long term.
> >
> >> Unlike the other possibilities that have been discussed this also
> >> addresses the nf_queue path as well as the nf_queue_hook_drop path.
> >
> > The nf_queue path should have been fine, no?
> >
> > Or putting it differently: can we start processing skbs before a netns
> > is fully initialized?
> 
> The practical case that worries me is what happens when someone does
> "rmmod nfnetlink_queue" while the system is running.  It appears to me
> that today we could free the per netns data during the rcu grace period
> and cause a similar issue in nfnl_queue_pernet.
>
> That looks like it could affect both the nf_queue path and the
> nf_queue_nf_hook_drop path.

OK, I'll check this again but I seem to recall this was fine (the
nfqueue module exit path sets the handler to NULL before doing anything
else).

The normal netns exit path should be fine too as exit and free happens
in two distinct loops, i.e. while (without your change) we can have
calls to nf_queue_hook_drop after the nfqueue netns exit function was
called, these calls will always happen before the pernets data is
freed.

Powered by blists - more mailing lists