linux-kernel - Re: possible regression of ptrace on 2.6.26-rc1

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: <20080508201150.AEEEE26FA85@magilla.localdomain>
Date:	Thu,  8 May 2008 13:11:50 -0700 (PDT)
From:	Roland McGrath <roland@...hat.com>
To:	wenji huang <wenji.huang@...cle.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: possible regression of ptrace on 2.6.26-rc1

The test is racy.  I don't think the behavior that affects this has really
changed between kernel versions, you're just seeing timing effects.

When you finish the loop, you've just done a PTRACE_SYSCALL to resume
the child, but have not done a wait for it.  You then do PTRACE_CONT on
it.  If the child has stopped at its next syscall report by the time
that ptrace call checks the child, it works.  If not, it sees the child
is not yet stopped and ptrace fails with ESRCH.  

Due to hysterical raisins, PTRACE_KILL skips the "child is stopped"
check, so it will never return that error.  However, a PTRACE_KILL
request made before the child has actually stopped will not reliably do
anything (it will set child->exit_code = SIGKILL in a race with the
child itself setting current->exit_code before it stops).

Thanks,
Roland
--
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/