From: Daniel Jacobowitz <dan@debian.org>
To: Nathan Field <nathan@cs.hmc.edu>
Cc: linux-kernel@vger.kernel.org
Subject: Re: BUG: PTRACE_POKETEXT modifies memory in related processes
Date: Thu, 31 Jan 2002 11:06:59 -0500 [thread overview]
Message-ID: <20020131110659.A6197@nevyn.them.org> (raw)
In-Reply-To: <Pine.GSO.4.32.0201310055030.23602-100000@turing.cs.hmc.edu>
In-Reply-To: <Pine.GSO.4.32.0201310055030.23602-100000@turing.cs.hmc.edu>
On Thu, Jan 31, 2002 at 02:43:00AM -0800, Nathan Field wrote:
> I believe I have found a bug in recent 2.4 linux kernels (at least 2.4.17)
> running on x86 related to using ptrace to modify a processes memory. From
> a quick scan of the 2.4.17 code it looks like ptrace.c:access_process_vm
> is not checking to see if the page of memory it is writing to has write
> permission, so it is not properly copy-on-write'ing. This means that if I
> have a simple program like this:
I don't think you're correctly understanding the circumstances. Are
you setting the breakpoint after they fork (seems unlikely, given this
test case - not much time to do so)? Otherwise, the breakpoint is
simply being carried over by your forking. Why you see it now and did
not before I don't know.
I see the same behavior with both software and hardware watchpoints.
Basically, GDB on Linux does not support fork very well. It doesn't
show up terribly often, because exec() clears breakpoints.
COW doesn't come into it. The page is being modified before it is
copied.
--
Daniel Jacobowitz Carnegie Mellon University
MontaVista Software Debian GNU/Linux Developer
next prev parent reply other threads:[~2002-01-31 16:07 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-01-31 10:43 BUG: PTRACE_POKETEXT modifies memory in related processes Nathan Field
2002-01-31 16:06 ` Daniel Jacobowitz [this message]
2002-02-02 4:32 ` PATCH: " Nathan Field
2002-02-02 7:39 ` Daniel Jacobowitz
2002-02-02 9:27 ` Nathan Field
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20020131110659.A6197@nevyn.them.org \
--to=dan@debian.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nathan@cs.hmc.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox