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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <4352991a1002111043l35f1c1b5mcd9ad4c76f6351a7@mail.gmail.com>
Date:	Thu, 11 Feb 2010 10:43:59 -0800
From:	Salman Qazi <sqazi@...gle.com>
To:	Oleg Nesterov <oleg@...hat.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 Thu, Feb 11, 2010 at 8:50 AM, Oleg Nesterov <oleg@...hat.com> wrote:
> On 02/11, Salman Qazi wrote:
>>
>> On Thu, Feb 11, 2010 at 4:56 AM, Oleg Nesterov <oleg@...hat.com> wrote:
>> >
>> > But this all is correct, you can't expect PTRACE_SYSCALL can succeed
>> > is the tracee is running, it must be stopped or traced.
>> >
>> > The tracee is running because it was TASK_STOPPED and antagonist()
>> > sends SIGCONT.
>> >
>> > The tracee was TASK_STOPPED because the tracer passes sig = SIGSTOP
>> > via ptrace(PTRACE_SYSCALL, WSTOPSIG(status).
>> >
>> > Where do you see the bug?
>>
>> Shouldn't ptrace(PTRACE_SYSCALL, WSTOPSIG(status)...), cause any
>> future signals to the child be intercepted by the parent?
>
> Not sure I understand your question. Of course the tracee will report any
> future signals signals, after it has a chance to dequeue a signal.
>
> But if you mean that after, say, ptrace(PTRACE_SYSCALL, SIGTERM) the
> tracee should report _this_ SIGTERM to the tracer - then no. Well,
> actually "this depends", but if PTRACE_SYSCALL (or any other req)
> is called after the tracee reported the signal - no. The signal was
> already reported.
>
>> >        int main(void)
>> >        {
>> >                int stat, ret;
>> >                int pid = fork();
>> >
>> >                if (!pid) {
>> >                        ptrace(PTRACE_TRACEME, 0, NULL, NULL);
>> >                        for (;;)
>> >                                ;
>> >                }
>> >
>> >                sleep(1);       // wait for PTRACE_TRACEME
>> >                kill(pid, SIGSTOP);
>> >
>> >                // the child reports SIGSTOP, it is TASK_TRACED
>> >                assert(pid == wait(&stat) && WIFSTOPPED(stat));
>> >
>> >                // the tracee should stop, we pass sig = SIGSTOP
>> >                assert(ptrace(PTRACE_SYSCALL, pid, 0, WSTOPSIG(stat)) == 0);
>> >
>> >                // the child reports the group stop, it is TASK_STOPPED
>> >                assert(pid == wait(&stat) && WIFSTOPPED(stat));
>> >
>> >                // the tracee is STOPPED as requested, not TRACED,
>> >                // SIGCONT wakes it up
>> >                kill(pid, SIGCONT);

I am still missing something.  There's probably a gap in my
understanding, so let's try to clarify it.  The last "kill" call,
sends a SIGCONT.  But, shouldn't this SIGCONT be intercepted by the
tracer before the tracee sees it?

>>
>>                    According to the man page, any signals to the
>> process are supposed to be intercepted by the parent and that is how
>> one is supposed to be able to control which signals make it to the
>> child.  I am not sure if it makes any difference if the signal
>> originates at the parent.  But in our test case, it doesn't.   So, why
>> doesn't the parent get a notification first?
>
> It does. You can insert another wait() (or just sleep(1)) between
> kill(SIGCONT) and PTRACE_SYSCALL below, the tracee will stop to report
> SIGCONT and the tracer will be notified. In this case the following
> PTRACE_SYSCALL should succeed.
>
> Perhaps I should have mentioned that the code above is racy. It is,
> I only did it to simplify the explanations.
>
> 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/