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: <4352991a1002111108n2be5f432i9484d2e8869daaa9@mail.gmail.com>
Date:	Thu, 11 Feb 2010 11:08:24 -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.

I understand what it does.  But, why is it the right thing to do?
>From the user's perspective, why should the task become untraced if we
use ptrace to deliver the signal?  Doesn't this make it impossible to
intercept and control which signals are sent to a traced task?

On Thu, Feb 11, 2010 at 10:55 AM, Oleg Nesterov <oleg@...hat.com> wrote:
> On 02/11, Salman Qazi wrote:
>>
>> >> >                // 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?
>
> No. The tracee resumes (again: because it was STOPPED, not TRACED),
> dequeues SIGCONT, reports the signal and stops in TASK_TRACED,
> see ptrace_signal(). Meanwhile, until it calls ptrace_stop(), it is
> TASK_RUNNING and ptrace() fails.
>
> 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/