linux-kernel - Re: [PATCH 1/2] wait/ptrace: always assume _

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]

Message-Id: <20151021124737.53825611940d7a353fee2bca@linux-foundation.org>
Date:	Wed, 21 Oct 2015 12:47:37 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Oleg Nesterov <oleg@...hat.com>
Cc:	Dmitry Vyukov <dvyukov@...gle.com>,
	Alexander Potapenko <glider@...gle.com>,
	Denys Vlasenko <dvlasenk@...hat.com>,
	Eric Dumazet <edumazet@...gle.com>,
	Jan Kratochvil <jan.kratochvil@...hat.com>,
	Julien Tinnes <jln@...gle.com>,
	Kees Cook <keescook@...gle.com>,
	Kostya Serebryany <kcc@...gle.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	"Michael Kerrisk (man-pages)" <mtk.manpages@...il.com>,
	Pedro Alves <palves@...hat.com>,
	Robert Swiecki <swiecki@...gle.com>,
	Roland McGrath <roland@...k.frob.com>,
	syzkaller@...glegroups.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] wait/ptrace: always assume __WALL if the child is
 traced

On Wed, 21 Oct 2015 19:41:50 +0200 Oleg Nesterov <oleg@...hat.com> wrote:

> On 10/20, Andrew Morton wrote:
> >
> > On Tue, 20 Oct 2015 19:17:54 +0200 Oleg Nesterov <oleg@...hat.com> wrote:
> >
> > > The following program (simplified version of generated by syzkaller)
> > >
> > > 	#include <pthread.h>
> > > 	#include <unistd.h>
> > > 	#include <sys/ptrace.h>
> > > 	#include <stdio.h>
> > > 	#include <signal.h>
> > >
> > > 	void *thread_func(void *arg)
> > > 	{
> > > 		ptrace(PTRACE_TRACEME, 0,0,0);
> > > 		return 0;
> > > 	}
> > >
> > > 	int main(void)
> > > 	{
> > > 		pthread_t thread;
> > >
> > > 		if (fork())
> > > 			return 0;
> > >
> > > 		while (getppid() != 1)
> > > 			;
> > >
> > > 		pthread_create(&thread, NULL, thread_func, NULL);
> > > 		pthread_join(thread, NULL);
> > > 		return 0;
> > > 	}
> > >
> > > creates the unreapable zombie if /sbin/init doesn't use __WALL.
> > >
> > > This is not a kernel bug, at least in a sense that everything works as
> > > expected: debugger should reap a traced sub-thread before it can reap
> > > the leader, but without __WALL/__WCLONE do_wait() ignores sub-threads.
> > >
> > > Unfortunately, it seems that /sbin/init in most (all?) distributions
> > > doesn't use it and we have to change the kernel to avoid the problem.
> >
> > Well, to fix this a distro needs to roll out a new kernel.  Or a new
> > init(8).  Is there any reason to believe that distributing/deploying a
> > new kernel is significantly easier for everyone? Because fixing init
> > sounds like a much preferable solution to this problem.
> 
> I will be happy if we decide that this is userpace problem and we should
> not fix the kernel. I simply do not know.

The kernel patch sounds pretty sketchy - something we should avoid
doing if at all possible.

> However, please look at 2/2 which imho makes sense regardless and looks
> "obviously safe". Without this patch waitid() can not use __WALL, so if
> /sbin/init uses waitid() then the userspace fix won't be one-liner. And
> at least Fedora22 and Ubuntu use waitid().

2/2 does look sensible (needs a better changelog if it's to be a
standalone thing), but if we're expecting distros to fix this with an
updated init(8) only, then they can't assume that the kernel's waitid()
has been altered.  So init will need the not-one-liner version of the
fix.

> So personally I'd prefer 2/2 + fix-init, not sure if this can work...

I'm just guessing here.  Are you (or someone) able to find out which
approach the distros will prefer, and why?

And what has to be done to init(8) to fix this bug when running current
kernels?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/