linux-kernel - Re: [PATCH 2/3] pidns: Guarantee that the pidns init will be the last pidns process reaped.

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:	Wed, 16 May 2012 13:54:17 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Oleg Nesterov <oleg@...hat.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Pavel Emelyanov <xemul@...allels.com>,
	Cyrill Gorcunov <gorcunov@...nvz.org>,
	Louis Rilling <louis.rilling@...labs.com>,
	Mike Galbraith <efault@....de>
Subject: Re: [PATCH 2/3] pidns: Guarantee that the pidns init will be the last pidns process reaped.

Oleg Nesterov <oleg@...hat.com> writes:

> Eric, sorry for the huge delay, I was on vacation when you sent this patch...
>
> On 05/06, Eric W. Biederman wrote:
>>
>> @@ -798,6 +815,12 @@ static void forget_original_parent(struct task_struct *father)
>>  	exit_ptrace(father);
>>  	reaper = find_new_reaper(father);
>>
>> +	/* Return immediately if we aren't going to reparent anything */
>> +	if (unlikely(reaper == father)) {
>> +		write_unlock_irq(&tasklist_lock);
>> +		return;
>> +	}
>
> I was confused by the comment. Afaics, it is not that "we aren't
> going to reparent", we need this change because we can't "reparent"
> to the same thread, list_for_each_entry_safe() below can never stop.
> But this is off-topic...

True.  We will get stuck if we try to reparent to the same process.

> Hmm. I don't think the patch is 100% correct. Afaics, this needs more
> delay_pidns_leader() checks.
>
> For example. Suppose we have a CLONE_NEWPID zombie I, it has an
> EXIT_DEAD child D so delay_pidns_leader(I) == T.
>
> Now suppose that I->real_parent exits, lets denote this task as P.
>
> Suppose that P->real_parent ignores SIGCHLD.
>
> In this case P will do release_task(I) prematurely. And worse, when
> D finally does realease_task(D) it will do realease_task(I) again.

Good point.  I will fix that and post a patch shortly.  It doesn't
need a full delay_pidns_leader test just a test for children.

In looking for any other weird corner case bugs I am noticing that
I don't think I handled the case of a ptraced init quite right.
I don't understand the change signaling semantics when the
ptracer is our parent.

Eric
--
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/