linux-kernel - Re: [PATCHv4] ptrace: make former thread ID available via PTRACE_GETEVENTMSG after PTRACE_EVENT

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: <20110701170559.GA12402@redhat.com>
Date:	Fri, 1 Jul 2011 19:05:59 +0200
From:	Oleg Nesterov <oleg@...hat.com>
To:	Denys Vlasenko <vda.linux@...glemail.com>
Cc:	Tejun Heo <tj@...nel.org>, linux-kernel@...r.kernel.org
Subject: Re: [PATCHv4] ptrace: make former thread ID available via
	PTRACE_GETEVENTMSG after PTRACE_EVENT_EXEC stop

On 06/29, Denys Vlasenko wrote:
>
> When multithreaded program execs under ptrace,
> all traced threads report WIFEXITED status, except for
> thread group leader and the thread which execs.
>
> Unless tracer tracks thread group relationship between tracees,
> which is a nontrivial task, it will not detect that
> execed thread no longer exists.
>
> This patch allows tracer to figure out which thread
> performed this exec, by requesting PTRACE_GETEVENTMSG
> in PTRACE_EVENT_EXEC stop.
>
> Another, samller problem which is solved by this patch
> is that tracer now can figure out which of the several
> concurrent execs in multithreaded program succeeded.
>
> Signed-off-by: Denys Vlasenko <vda.linux@...glemail.com>

Thanks, applied.

> @@ -1370,6 +1371,11 @@ int search_binary_handler(struct linux_binprm *bprm,struct pt_regs *regs)
>  	if (retval)
>  		return retval;
>
> +	/* Need to fetch pid before load_binary changes it */
> +	rcu_read_lock();
> +	old_pid = task_pid_nr_ns(current, task_active_pid_ns(current->parent));
> +	rcu_read_unlock();
> +
>  	retval = -ENOENT;
>  	for (try=0; try<2; try++) {
>  		read_lock(&binfmt_lock);
> @@ -1389,7 +1395,8 @@ int search_binary_handler(struct linux_binprm *bprm,struct pt_regs *regs)
>  			bprm->recursion_depth = depth;
>  			if (retval >= 0) {
>  				if (depth == 0)
> -					ptrace_event(PTRACE_EVENT_EXEC, 0);
> +					ptrace_event(PTRACE_EVENT_EXEC,
> +							old_pid);

Just for record. ->parent can be changed after we call task_pid_nr_ns(),
and the new parent (tracer) can have another namespace, in this case
we report the wrong pid. This is possible even now, without
"PT_SEIZED implies PTRACE_EVENT_EXEC" we are going to add, although
this is very unlikely and in this case PTRACE_EVENT_EXEC is spurious
anyway. But when we change the behaviour of PT_SEIZED, this race
becomes not that exotic, although very unlikely anyway.

I do not think we should try to fix this, it is not trivial and
doesn't worth the trouble.

Oleg.

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