From: Tahar <tahar.jarboui@laas.fr>
To: root@chaos.analogic.com
Cc: David Chandler <chandler@grammatech.com>,
Benjamin LaHaise <bcrl@redhat.com>,
linux-kernel@vger.kernel.org
Subject: Re: Bug Report: Dereferencing a bad pointer
Date: Thu, 08 Nov 2001 18:53:47 +0100 [thread overview]
Message-ID: <3BEAC6AB.A6A35E73@laas.fr> (raw)
In-Reply-To: <Pine.LNX.3.95.1011108103553.22138A-100000@chaos.analogic.com>
Richard,
Your explanation shows why the process is not killed with a SIGSEGV, but
it don't points out why the process hangs !
"Richard B. Johnson" wrote:
>
> On Thu, 8 Nov 2001, David Chandler wrote:
>
> > Benjamin LaHaise wrote:
> >
> > > On Wed, Nov 07, 2001 at 06:23:13PM -0500, David Chandler wrote:
> > > > The following one-line C program, when compiled by gcc 2.96 without
> > > > optimization, should produce a SIGSEGV segmentation fault (on a machine
> > > > with 3 or less gigabytes of virtual memory, at least):
> > > >
> > > > int main() { int k = *(int *)0xc0000000; }
> > > >
>
> This may not necessarily produce a seg-fault! If this virtual
> address is mapped within the current process (.bss .stack, etc.),
> It's perfectly all right to write to it although you probably
> broke malloc() by doing it. The actual value of the number in
> the pointer depends upon PAGE_OFFSET and other kernel variables.
> If you change the kernel, this number may change. It has nothing
> to do with the size of virtual address space, really.
>
> Script started on Thu Nov 8 10:44:03 2001
> # cat >xxx.c
> #include <stdio.h>
> int bss;
> int data = 0x100;
> const char cons[]="X";
>
> main()
> {
> int stack;
>
> printf("main() = %p\n", main);
> printf("stack = %p\n", &stack);
> printf("const = %p\n", cons);
> printf(" data = %p\n", &data);
> printf(" bss = %p\n", &bss);
> return 0;
>
> }
>
> # gcc -o xxx xxx.c
> # ./xxx
> main() = 0x80484cc
> stack = 0xbffff6fc
> const = 0x8048584
> data = 0x80495d4
> bss = 0x80496b8
> # exit
> exit
>
> Script done on Thu Nov 8 10:44:27 2001
>
> All this stuff you "own". You can write to most all of it because
> the kernel has allocated it for you. Whether or not 'const' is
> really read-only is "implementation dependent".
>
> In your case, it looks as though you scribbled over the top of
> your user stack, in some harmless place.
>
> You cannot presume that a program that doesn't seg-fault is
> memory-error free. Protection is in pages, not bytes, and you
> already own a lot of address-space that you may think that
> you don't. FYI, if you allocate a lot of memory using malloc(),
> it sets the break address to acquire more memory. Then if you
> free that memory, it does not necessarily give back the memory.
>
> You may be able to write to freed memory without a seg-fault.
> However, subsequent calls to malloc() may fail because you have
> ticked-off malloc() and it's gonna get even.
>
> Cheers,
> Dick Johnson
>
> Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).
>
> I was going to compile a list of innovations that could be
> attributed to Microsoft. Once I realized that Ctrl-Alt-Del
> was handled in the BIOS, I found that there aren't any.
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
next prev parent reply other threads:[~2001-11-08 17:55 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-11-07 23:23 Bug Report: Dereferencing a bad pointer David Chandler
2001-11-07 23:40 ` Benjamin LaHaise
2001-11-08 15:29 ` David Chandler
2001-11-08 16:02 ` Richard B. Johnson
2001-11-08 17:17 ` David Chandler
2001-11-08 21:32 ` Richard B. Johnson
2001-11-08 21:57 ` David Chandler
2001-11-08 22:39 ` Brian Gerst
2001-11-08 23:15 ` David Chandler
2001-11-09 13:33 ` Richard B. Johnson
2001-11-08 17:53 ` Tahar [this message]
2001-11-08 16:27 ` Benjamin LaHaise
2001-11-08 18:02 ` Alan Cox
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=3BEAC6AB.A6A35E73@laas.fr \
--to=tahar.jarboui@laas.fr \
--cc=bcrl@redhat.com \
--cc=chandler@grammatech.com \
--cc=jarboui@laas.fr \
--cc=linux-kernel@vger.kernel.org \
--cc=root@chaos.analogic.com \
/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