Bug Report: Dereferencing a bad pointer

Bug Report: Dereferencing a bad pointer

[David Chandler]

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

Re: Bug Report: Dereferencing a bad pointer

[Benjamin LaHaise]

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; }
> 
> However, it does not do so under 2.4.x -- it does cause a seg fault
> under
> 2.2.x kernels.

Works here running 2.4.13-ac8+bits.  Are you sure you didn't compile with 
optimization enabled?

		-ben

Re: Bug Report: Dereferencing a bad pointer

[David Chandler]

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; }
> >
> > However, it does not do so under 2.4.x -- it does cause a seg fault
> > under
> > 2.2.x kernels.
>
> Works here running 2.4.13-ac8+bits.  Are you sure you didn't compile with
> optimization enabled?
>
>                 -ben

I'm quite sure -- an optimized build exits immediately, whereas I'm seeing a
hung process with 2.4 kernels that has to be killed (most any signal,
including SIGSEGV, will do the trick).  With 2.2 kernels, the program seg
faults, as it should.  By "Works here" I assume you mean that you received a
segmentation fault.

I get the same result with gcc 3.0.1 and gcc 2.96 (and yes, the relevant
generated code differs slightly).  I have tried Linus's official 2.4.13+UML
on UML, but I've not tried 2.4.13-ac8.

Please Cc: me on any replies.


David Chandler

_____
David L. Chandler.                              GrammaTech, Inc.
mailto:chandler@grammatech.com         http://www.grammatech.com

Re: Bug Report: Dereferencing a bad pointer

[Richard B. Johnson]

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.

Re: Bug Report: Dereferencing a bad pointer

[David Chandler]

Dick,

You're right that the one-liner below may not necessarily produce a seg
fault, but shouldn't it terminate normally if it doesn't?  After all,
the program just *reads*.  Hanging does not seem to be an option!

BTW, your example program produces very similar output for the 2.4 and
2.2 kernels to which I have access.  I apologize for any confusion my
original report created -- 0xc0000000 was chosen because of its relation
to the start of the stack frame, and indeed it has nothing
to do with the size of virtual address space.


David Chandler


"Richard B. Johnson" 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.


> 
> 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.


> Cheers,
> Dick Johnson


-- 

_____
David L. Chandler.                              GrammaTech, Inc.
mailto:chandler@grammatech.com         http://www.grammatech.com

Re: Bug Report: Dereferencing a bad pointer

[Richard B. Johnson]

On Thu, 8 Nov 2001, David Chandler wrote:

> Dick,
> 
> You're right that the one-liner below may not necessarily produce a seg
> fault, but shouldn't it terminate normally if it doesn't?  After all,
> the program just *reads*.  Hanging does not seem to be an option!
> 
You may want to see if any deliberate seg-fault actually gets
delivered. Try to read *(0).  If that works (seg-faults), then
there may be a problem with some boundary condition on paging.

I can't duplicate the problem here. You can also try to trace
the code execution to see if it falls into some user-space loop.


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.

Re: Bug Report: Dereferencing a bad pointer

[David Chandler]

I get a seg fault on both 2.2 and 2.4 kernels by running the following
one-line C program:
	int main() { int k =  (int *)0x0; }

Debugging the offender,
	int main() { int k =  (int *)0xc0000000; }
is not very informative: single-stepping over the sole command just
hangs, and you have to press Control-C to interrupt gdb, at which point
you can single-step right into the same problem again.

When the program hangs, 'top' says that the CPU is fully utilized and
the system is spending 80% of its time in the kernel and 20% in the
offending process.

Have you not been able to duplicate it on a 2.4 kernel on x86?  If not,
please tell me which 2.4 kernel correctly seg faults.


David Chandler

-- 

_____
David L. Chandler.                              GrammaTech, Inc.
mailto:chandler@grammatech.com         http://www.grammatech.com


"Richard B. Johnson" wrote:
> 
> On Thu, 8 Nov 2001, David Chandler wrote:
> 
> > Dick,
> >
> > You're right that the one-liner below may not necessarily produce a seg
> > fault, but shouldn't it terminate normally if it doesn't?  After all,
> > the program just *reads*.  Hanging does not seem to be an option!
> >
> You may want to see if any deliberate seg-fault actually gets
> delivered. Try to read *(0).  If that works (seg-faults), then
> there may be a problem with some boundary condition on paging.
> 
> I can't duplicate the problem here. You can also try to trace
> the code execution to see if it falls into some user-space loop.
> 
> 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.

Re: Bug Report: Dereferencing a bad pointer

[Brian Gerst]

David Chandler wrote:
> 
> I get a seg fault on both 2.2 and 2.4 kernels by running the following
> one-line C program:
>         int main() { int k =  (int *)0x0; }
> 
> Debugging the offender,
>         int main() { int k =  (int *)0xc0000000; }
> is not very informative: single-stepping over the sole command just
> hangs, and you have to press Control-C to interrupt gdb, at which point
> you can single-step right into the same problem again.
> 
> When the program hangs, 'top' says that the CPU is fully utilized and
> the system is spending 80% of its time in the kernel and 20% in the
> offending process.
> 
> Have you not been able to duplicate it on a 2.4 kernel on x86?  If not,
> please tell me which 2.4 kernel correctly seg faults.

How about address 0xc0001000?  I have been unable to reproduce this on a
PII running 2.4.9, and an Athlon running 2.4.14.

--

				Brian Gerst

Re: Bug Report: Dereferencing a bad pointer

[David Chandler]

0xc0001000 hangs the same way that 0xc0000000 does.  I have reproduced
this on a 2.4.9+UML kernel running in user-mode linux on top of a
Pentium-4 2.4.2-2(RedHat) host.  'top' says that 75% of CPU is going to
the system in that case also.

Please Cc: me on any replies.


David Chandler
--
_____
David L. Chandler.                              GrammaTech, Inc.
mailto:chandler@grammatech.com         http://www.grammatech.com



Brian Gerst wrote:
> 
> David Chandler wrote:
> >
> > Debugging the offender,
> >         int main() { int k =  (int *)0xc0000000; }
> > is not very informative: single-stepping over the sole command just
> > hangs, and you have to press Control-C to interrupt gdb, at which point
> > you can single-step right into the same problem again.
> >
> > When the program hangs, 'top' says that the CPU is fully utilized and
> > the system is spending 80% of its time in the kernel and 20% in the
> > offending process.
> >
> > Have you not been able to duplicate it on a 2.4 kernel on x86?  If not,
> > please tell me which 2.4 kernel correctly seg faults.
> 
> How about address 0xc0001000?  I have been unable to reproduce this on a
> PII running 2.4.9, and an Athlon running 2.4.14.
> 
> --
> 
>                                 Brian Gerst

Re: Bug Report: Dereferencing a bad pointer

[Richard B. Johnson]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1725 bytes --]

On Thu, 8 Nov 2001, David Chandler wrote:

> I get a seg fault on both 2.2 and 2.4 kernels by running the following
> one-line C program:
> 	int main() { int k =  (int *)0x0; }
> 
> Debugging the offender,
> 	int main() { int k =  (int *)0xc0000000; }
> is not very informative: single-stepping over the sole command just
> hangs, and you have to press Control-C to interrupt gdb, at which point
> you can single-step right into the same problem again.
> 
> When the program hangs, 'top' says that the CPU is fully utilized and
> the system is spending 80% of its time in the kernel and 20% in the
> offending process.
> 
> Have you not been able to duplicate it on a 2.4 kernel on x86?  If not,
> please tell me which 2.4 kernel correctly seg faults.
> 
> 
> David Chandler
> 

Linux 2.4.1 seg-faults fine. Here is a test program that does not
use 'C' or the C runtime library. An assembly language program
is generated by this script. The first run just exits to the
Operating System using the Linux system call via interrupt 0x80.
The second run reads whatever is at virtual offset address 0xc000000
then attempts to exit to the OS. It checks to see if a core file
was generated (to see if it seg-faulted).

Try this out. If it properly seg-faults, you may have a 'C' compiler
that has optimized your offending line right out of existence!

If it doesn't work, you have truly discovered some problem with the
kernel version that doesn't work.

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.


[-- Attachment #2: Type: TEXT/PLAIN, Size: 774 bytes --]

FILE=/tmp/grok

cat <<EOF >${FILE}.s
.section	.text
.global	_start
.type	_start,@function

_start:
	movl	\$0xc0000000, %ebx
#	movl	(%ebx), %eax
	movl	\$1, %eax
	xorl	%ebx,%ebx
	int	\$0x80
EOF
as -o ${FILE}.o ${FILE}.s
ld -o ${FILE} ${FILE}.o
chmod +x ${FILE}
echo "This should execute fine"
rm -f core
${FILE}
if [ -f core ] ; then
   echo "Failed"
else
   echo "Okay"
fi
cat <<EOF >${FILE}.s
.section	.text
.global	_start
.type	_start,@function

_start:
	movl	\$0xc0000000, %ebx
	movl	(%ebx), %eax
	movl	\$1, %eax
	xorl	%ebx,%ebx
	int	\$0x80
EOF
as -o ${FILE}.o ${FILE}.s
ld -o ${FILE} ${FILE}.o
chmod +x ${FILE}
echo "This should seg-fault"
${FILE}
if [ -f core ] ; then
   echo "Okay"
else
   echo "Failed"
fi
rm -f core

Re: Bug Report: Dereferencing a bad pointer

[Tahar]

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/

Re: Bug Report: Dereferencing a bad pointer

[Benjamin LaHaise]

On Thu, Nov 08, 2001 at 10:29:19AM -0500, David Chandler wrote:
> I get the same result with gcc 3.0.1 and gcc 2.96 (and yes, the relevant
> generated code differs slightly).  I have tried Linus's official 2.4.13+UML
> on UML, but I've not tried 2.4.13-ac8.

Perhaps you should try -ac?

		-ben

Re: Bug Report: Dereferencing a bad pointer

[Alan Cox]

> On Thu, Nov 08, 2001 at 10:29:19AM -0500, David Chandler wrote:
> > I get the same result with gcc 3.0.1 and gcc 2.96 (and yes, the relevant
> > generated code differs slightly).  I have tried Linus's official 2.4.13+UML
> > on UML, but I've not tried 2.4.13-ac8.
> 
> Perhaps you should try -ac?

If you do then use ac7 for x86