linux-kernel - Re: Race in ptrace.

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20100211205929.GA27038@redhat.com>
Date:	Thu, 11 Feb 2010 21:59:29 +0100
From:	Oleg Nesterov <oleg@...hat.com>
To:	Salman Qazi <sqazi@...gle.com>
Cc:	taviso@...gle.com, Roland Dreier <rolandd@...co.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Roland McGrath <roland@...hat.com>,
	linux-kernel@...r.kernel.org
Subject: Re: Race in ptrace.

On 02/11, Salman Qazi wrote:
>
> On Thu, Feb 11, 2010 at 12:10 PM, Oleg Nesterov <oleg@...hat.com> wrote:
> >>
> > Why? The tracee reports all signals. If the tracer does
> > ptrace(PTRACE_WHATEVER, SIGXXX) surely it knows SIGXXX is sent to
> > tracee.
>
> The ptrace syscall fails, as the child is running and so we are unable
> to restart the child.  I suppose it is not accurate to say "impossible
> to intercept" if it eventually works.  But, it's an unpleasant
> behaviour.  How do you distinguish between this race and the child
> suddenly becoming untraced or dying?

The child can't become untraced unless the tracer detaches. If the
tracee dies the tracer can notice this via wait(). And please note
again, this particular case is not possible when the tracee is
TASK_TRACED. The tracer explicitly instructed the tracee to stop in
TASK_STOPPED, it should take care of SIGCONT case.

But don't get me wrong, see below,

> > In any case. This is how ptrace currently works, there is no race
> > and the patch is not needed (in fact it is very wrong, but this
> > soesn't matter).
> >
> > Do you agree?
>
> I agree that the patch is wrong because of the reasons you mentioned
> earlier.  But I think there is an issue here.  It's hard to say what
> it is supposed to do, but I can certainly see it being more useful
> this behaviour wasn't there.

Ha. let me repeat, nobody thinks the current ptrace API is nice.


OK. Thanks Salman for your report and discussion.

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/