[Bug libc/12197] New: ptrace seems to clobber pid argument

[Bug libc/12197] New: ptrace seems to clobber pid argument

[eteran at alum dot rit.edu]

http://sourceware.org/bugzilla/show_bug.cgi?id=12197

           Summary: ptrace seems to clobber pid argument
           Product: glibc
           Version: 2.12
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
        AssignedTo: drepper.fsp@gmail.com
        ReportedBy: eteran@alum.rit.edu


Created attachment 5113
  --> http://sourceware.org/bugzilla/attachment.cgi?id=5113
test case that fails on my machine.

I have encountered some very weird behavior where calling ptrace with
PTRACE_GETEVENTMSG causes the variable passed as the pid to be set to 0 after
the call.

Certainly this is not the expected behavior since the documentation seems to
indicate that the only "out" parameter is the data parameter.

I've created a basic test case that triggers this issue on my system (gentoo
linux x86-64, gcc-4.5.1, glibc-2.11.2-r3, gentoo-sources-2.6.34-r6).

I will attach the test case that I've created. It uses a clone event to give
reason to do a PTRACE_GETEVENTMSG ptrace request. Afterwards, the pid variable
is set to 0 for some reason.

PS: As a side note. I think I understand why ptrace is a variadic function as
this enables variables of different types to be passed. But why is the pid
passed as one of the variadic parameter? That parameter should always be of
type pid_t right? I would have guessed that the prototype could just as easily
be:

long ptrace(enum __ptrace_request request, pid_t pid, ...);

Thanks,
Evan Teran

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug libc/12197] ptrace seems to clobber pid argument

[drepper.fsp at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=12197

Ulrich Drepper <drepper.fsp at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID

--- Comment #1 from Ulrich Drepper <drepper.fsp at gmail dot com> 2010-11-08 20:32:04 UTC ---
(In reply to comment #0)
> I have encountered some very weird behavior where calling ptrace with
> PTRACE_GETEVENTMSG causes the variable passed as the pid to be set to 0 after
> the call.

It completely depends on the way you compile your code because you added a
buffer overrun in your code.  The pointer passed to ptrace must be a long, not
an int.  Obviously you are damaging other variables.  Why wouldn't you first
make sure your code is correct before bothering others?  Debugging byproxy is
simpler, right?

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug libc/12197] ptrace seems to clobber pid argument

[eteran at alum dot rit.edu]

http://sourceware.org/bugzilla/show_bug.cgi?id=12197

--- Comment #2 from Evan Teran <eteran at alum dot rit.edu> 2010-11-08 21:02:47 UTC ---
It was not my intention to "debug by proxy". I did not realize that
PTRACE_GETEVENTMSG required an unsigned long, without that particular detail
the bug is unfortunately, non-obvious.

I've re-read the man page and you are of course correct. Sorry for the invalid
bug report.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug libc/12197] ptrace seems to clobber pid argument

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=12197

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
              Flags|                            |security-

-- 
You are receiving this mail because:
You are on the CC list for the bug.