[OCLUG-devel] arrays

[Dan Stromberg]

On Sun, 2005-05-29 at 11:20 -0700, James Colannino wrote:
> Christopher Smith wrote:
> 
> > C doesn't have any bounds checking so it's not going to stop you from
> > accessing data outside the array. Now, depending on how the allocator
> > is setup, there may be some "padding" around your array that prevents
> > really bad things from happening. In terms of what could go wrong?
> > Well, this is a classic example of how stack overflows occur. You're
> > writing past the end of the stack-allocated array, which means you're
> > writing all over the stack. I'm guessing you aren't having a problem
> > because you're exiting immediately after this. However, if this was in
> > a subroutine, then when you return, the subroutine would pop off the 5
> > bytes of your array and any arguments that were passed in, and then
> > pop off the return address. If the return address has been overwritten
> > by your array data, then it'll jump somewhere unanticipated. In most
> > cases this will be a segmentation fault because it'll be a totally
> > invalid address (which should be happening in this case). Sometimes
> > though, you can be unfortunate enough to write in an address that is
> > valid, at which your program will jump to that location and attempt to
> > execute instructions. Very, very messy.
> 
> 
> By the way, I'm just curious, does the kernel ever do anything about a
> situation in which a process attempts to execute corrupted
> instructions?  I guess there's probably not much it could do, but does
> the kernel at least protect you from truly dangerous things that could
> result from the random contents of a variable being executed as
> instructions?  I'm guessing that since the kernel takes full control of
> the hardware it would probably protect you at least to a certain
> extent.  Perhaps such a thing could cause a kernel panic?

I'm not sure what was done to resolve the problem, but years ago there
was a program called "crashme" that generated a bunch of random code and
executed it, which would crash most *ix's, including linux.

But linux adapted to it.  I'm not sure how many of the *ix vendors
followed suit.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://localhost.localdomain/pipermail/oclug-devel/attachments/20050529/5675450e/attachment.bin