linux-kernel - Re: [PATCH] kernel/exit.c: make sure current's nsproxy != NULL while checking caps

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]

Date:	Mon, 1 Dec 2014 13:08:46 -0800 (PST)
From:	David Rientjes <rientjes@...gle.com>
To:	Lukasz Pawelczyk <l.pawelczyk@...sung.com>
cc:	Lukasz Pawelczyk <havner@...il.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Oleg Nesterov <oleg@...hat.com>, Michal Hocko <mhocko@...e.cz>,
	Sameer Nanda <snanda@...omium.org>,
	Guillaume Morin <guillaume@...infr.org>,
	Li Zefan <lizefan@...wei.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] kernel/exit.c: make sure current's nsproxy != NULL while
 checking caps

On Thu, 27 Nov 2014, Lukasz Pawelczyk wrote:

> On śro, 2014-11-26 at 13:32 -0800, David Rientjes wrote:
> > On Wed, 26 Nov 2014, Lukasz Pawelczyk wrote:
> > > 
> > > LSM task_kill() hook is triggered and current->nsproxy within is NULL.
> > > 
> > > This happens during an exit() syscall because exit_task_namespaces() is
> > > called before the exit_notify(). This patch changes their order.
> > > 
> > 
> > This is a classic case of a patch being proposed for a problem that only 
> > occurs on kernels that include other patches that are not upstream.  The 
> > order that things are deconstructed in the exit path is complex and 
> > carefully choreographed, changing it comes at significant risk.  That risk 
> > would be justified if a patch were being proposed for upstream that fixes 
> > an upstream problem.  It becomes too much of a maintenance nightmare to 
> > try to address problems and keep issues from arising for non-upstream 
> > patches.  Thus, I don't think this is something that we want.
> 
> This is a problem for the change I'm working on and I will be
> upstreaming it too at some point. Please see my other reply for more
> details:
> 
> http://www.spinics.net/lists/kernel/msg1877152.html
> 
> The only thing I can do then is to post this patch together with the
> other patches when the time comes. But since this issue is rather
> separate I've decided to try to push it earlier.
> 

Yeah, it would be best to fold this into a series that needs 
current->nsproxy to be valid at a sequence point in the exit path as part 
of the same patch that requires it.