From: David Chandler <chandler@grammatech.com>
To: linux-kernel@vger.kernel.org
Subject: Bug Report: Dereferencing a bad pointer
Date: Wed, 07 Nov 2001 18:23:13 -0500 [thread overview]
Message-ID: <3BE9C261.D7422143@grammatech.com> (raw)
Bug Report
Summary:
Dereferencing a bad pointer in user space hangs rather than causing a
segmentation fault in 2.4.x kernels.
Keywords:
memory protection address dereference segmentation fault SIGSEGV
Full Description:
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; }
However, it does not do so under 2.4.x -- it does cause a seg fault
under
2.2.x kernels.
Specifically, no seg fault occurs under kernels 2.4.2-2 (Red Hat build),
2.4.13, 2.4.13UML, 2.4.9UML, or 2.4.8UML. This one-liner does cause a
seg fault on 2.2.5-15 (Red Hat build) and 2.2.14-5.0 (Red Hat build).
All these were run on Pentium II, Pentium III, and Pentium 4 chips.
The "UML" kernels are Linus's official releases patched with the
user-mode linux patches and run on a Red Hat 7.1 2.4.2-2 Pentium 4 host;
Tom's rtbt was the UML file system.
Note that UML uses arch/um rather than arch/i386; this seems to remove
some suspicion from 'arch/i386/mm/fault.c', which has changed
considerably from 2.2.x to 2.4.x.
Rather than seg faulting, the 2.4.x kernels just sit at the offensive
dereference until you interrupt the process. Interruption works
flawlessly; you can use 'kill -INT', 'kill -SEGV' or 'kill -BUS' to
interrupt the process.
Please Cc: me on any responses -- the linux-kernel traffic is too much
for me.
David Chandler
--
_____
David L. Chandler. GrammaTech, Inc.
mailto:chandler@grammatech.com http://www.grammatech.com
next reply other threads:[~2001-11-07 23:23 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-11-07 23:23 David Chandler [this message]
2001-11-07 23:40 ` Bug Report: Dereferencing a bad pointer 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
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=3BE9C261.D7422143@grammatech.com \
--to=chandler@grammatech.com \
--cc=linux-kernel@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.