Overwriting Allocated Memory from malloc()

[tweak]

I have been messing around with buffers, and
I found it peculiar that the code below will
run without a segmentation fault.

As far as I know, overwriting the allocated space
from a call to malloc() results in undefined
behavior.

Any ideas why overwriting the dynamically
assigned space doesn't cause a segmentation
fault?

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <errno.h>

int
main(void)
{

char *ptr = NULL;
char buffer[256]; /* intentionally did not initialize */
int y = 0;

if ( ( ptr = malloc(1) ) == 0 ) {
perror("malloc() problem");
exit(1);
}

for ( int i; i < 255; i++ )
buffer[i] = 'Z';

while ( (ptr[y] = buffer[y]) != '\0' )
y++;
(void)printf("ptr is: %s\n", ptr);
free(ptr);

return 0;
}

[Eric Amick]

On Thu, 08 Jul 2004 18:22:16 -0700, tweak <xb**********@cox.net> wrote:

As far as I know, overwriting the allocated space
from a call to malloc() results in undefined
behavior.

Any ideas why overwriting the dynamically
assigned space doesn't cause a segmentation
fault?

Because undefined behavior by definition can be anything at all. You
were lucky, nothing more.

--
Eric Amick
Columbia, MD

[Lewis Bowers]

tweak wrote:

I have been messing around with buffers, and
I found it peculiar that the code below will
run without a segmentation fault.

As far as I know, overwriting the allocated space
from a call to malloc() results in undefined
behavior.

Any ideas why overwriting the dynamically
assigned space doesn't cause a segmentation
fault?

Why would you expect undefined behavior(UB) to cause seg fault?
To me, UB seems to suggest that anything can happen; good, bad, expected

or unexpected.

[Barry Schwarz]

On Thu, 08 Jul 2004 18:22:16 -0700, tweak <xb**********@cox.net>
wrote:

I have been messing around with buffers, and
I found it peculiar that the code below will
run without a segmentation fault.

As far as I know, overwriting the allocated space
from a call to malloc() results in undefined
behavior.

Any ideas why overwriting the dynamically
assigned space doesn't cause a segmentation
fault?
Undefined behavior is not guaranteed to cause a segment fault. In its
most pernicious form, it appears to work properly until it can satisfy
one of Murphy's laws.

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <errno.h>

int
main(void)
{

char *ptr = NULL;
char buffer[256]; /* intentionally did not initialize */
int y = 0;

if ( ( ptr = malloc(1) ) == 0 ) {
perror("malloc() problem");
exit(1);
}

for ( int i; i < 255; i++ )
buffer[i] = 'Z';

while ( (ptr[y] = buffer[y]) != '\0' )
y++;
(void)printf("ptr is: %s\n", ptr);
free(ptr);

return 0;
}

<<Remove the del for email>>

[tweak]

Barry Schwarz wrote:

On Thu, 08 Jul 2004 18:22:16 -0700, tweak <xb**********@cox.net>
wrote:

I have been messing around with buffers, and
I found it peculiar that the code below will
run without a segmentation fault.

As far as I know, overwriting the allocated space

from a call to malloc() results in undefined

behavior.

Any ideas why overwriting the dynamically
assigned space doesn't cause a segmentation
fault?

Undefined behavior is not guaranteed to cause a segment fault. In its
most pernicious form, it appears to work properly until it can satisfy
one of Murphy's laws.

I tried different sizes of the buffer array, and I was able to generate
a segmentation fault. Since the compiler tells me everything is okay,
and since the software appears to work, are there any audit tools to
check for problems like this one, where the compiler doesn't warn of
a potential problem (beyond just the malloc() ones listed in the FAQ)?

I'm sure you grep or use an equivalent tool in the many different
OS's we have. But are there any portable tools?

Of course, writing ISO C99 code that is portable is preferred, but you
can miss stuff as the number of lines of code and number of files increase.

Brian

[Vijay Kumar R Zanvar]

"tweak" <xb**********@cox.net> wrote in message news:PJpHc.787$rr.721@fed1read02...

Barry Schwarz wrote:

On Thu, 08 Jul 2004 18:22:16 -0700, tweak <xb**********@cox.net>
wrote:

[..] I tried different sizes of the buffer array, and I was able to generate
a segmentation fault. Since the compiler tells me everything is okay,
and since the software appears to work, are there any audit tools to
check for problems like this one, where the compiler doesn't warn of
a potential problem (beyond just the malloc() ones listed in the FAQ)?

lint may be helpful. See below.
I'm sure you grep or use an equivalent tool in the many different
OS's we have. But are there any portable tools?

Of course, writing ISO C99 code that is portable is preferred, but you
can miss stuff as the number of lines of code and number of files increase.

Brian
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <errno.h>

int
main(void)
{

char *ptr = NULL;
char buffer[256]; /* intentionally did not initialize */
int y = 0;

if ( ( ptr = malloc(1) ) == 0 ) {
perror("malloc() problem");
exit(1);
}

for ( int i; i < 255; i++ )
i is uninitialized. UB.
buffer[i] = 'Z';

while ( (ptr[y] = buffer[y]) != '\0' )
y++;
(void)printf("ptr is: %s\n", ptr);
free(ptr);

return 0;
}

F:\>splint overflow.c
Splint 3.0.1.6 --- 11 Feb 2002

overflow2.c: (in function main)
overflow2.c(15,18): Unrecognized identifier: NULL
Identifier used in code has not been declared. (Use -unrecog to inhibit
warning)
overflow2.c(19,19): Unrecognized identifier: malloc
overflow2.c(20,10): Unrecognized identifier: perror
overflow2.c(21,10): Unrecognized identifier: exit
overflow2.c(27,15): Index of possibly null pointer ptr: ptr
A possibly null pointer is dereferenced. Value is either the result of a
function which may return null (in which case, code should check it is not
null), or a global, parameter or structure field declared with the null
qualifier. (Use -nullderef to inhibit warning)
overflow2.c(19,19): Storage ptr may become null
overflow2.c(27,24): Value buffer[] used before definition
An rvalue is used that may not be initialized to a value on some execution
path. (Use -usedef to inhibit warning)
overflow2.c(29,12): Unrecognized identifier: printf
overflow2.c(30,6): Unrecognized identifier: free

Finished checking --- 8 code warnings

[tweak]

Vijay Kumar R Zanvar wrote:

"tweak" <xb**********@cox.net> wrote in message news:PJpHc.787$rr.721@fed1read02...

Barry Schwarz wrote:

On Thu, 08 Jul 2004 18:22:16 -0700, tweak <xb**********@cox.net>
wrote:

[..]

I tried different sizes of the buffer array, and I was able to generate
a segmentation fault. Since the compiler tells me everything is okay,
and since the software appears to work, are there any audit tools to
check for problems like this one, where the compiler doesn't warn of
a potential problem (beyond just the malloc() ones listed in the FAQ)?

lint may be helpful. See below.

Thanks. I used google to find it. I will start using it tomorrow.
I also found a splint. I will look at them both when I have more
energy.

I'm sure you grep or use an equivalent tool in the many different
OS's we have. But are there any portable tools?

Of course, writing ISO C99 code that is portable is preferred, but you
can miss stuff as the number of lines of code and number of files increase.

Brian

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <errno.h>

int
main(void)
{

char *ptr = NULL;
char buffer[256]; /* intentionally did not initialize */
int y = 0;

if ( ( ptr = malloc(1) ) == 0 ) {
perror("malloc() problem");
exit(1);
}

for ( int i; i < 255; i++ )

i is uninitialized. UB.

Good catch. My source code reads as : for (int i = 0; i < 255; i++).
I made a typo.

Also since malloc() returns a NULL pointer on failure, the line that
starts with if should read:

if ( ( ptr = malloc(1) ) == NULL ) {

to be consistent even though it's just a style thing.

Thanks,

Brian

[Richard Bos]

tweak <xb**********@cox.net> wrote:

"tweak" <xb**********@cox.net> wrote in message news:PJpHc.787$rr.721@fed1read02...

if ( ( ptr = malloc(1) ) == 0 ) {

Also since malloc() returns a NULL pointer on failure,
No, it doesn't. It returns a null pointer. NULL is a macro, which
expands to a null pointer _constant_, and exists only in your source
code; a null pointer is an object, which exists during runtime.
the line that starts with if should read:

if ( ( ptr = malloc(1) ) == NULL ) {

to be consistent even though it's just a style thing.

There's nothing consistent about it. The original is just as good, just
as clear, and just as proper C. The only way in which this version could
be more, rather than just as, consistent, is if you've used NULL
everywhere else in your code; but that is consistency with _yourself_,
not with C. C does not distinguish between those two versions; both must
work equally well.

Richard

[Emmanuel Delahaye]

In 'comp.lang.c', Eric Amick <er********@comcast.net> wrote:

On Thu, 08 Jul 2004 18:22:16 -0700, tweak <xb**********@cox.net> wrote:

As far as I know, overwriting the allocated space
from a call to malloc() results in undefined
behavior.

Any ideas why overwriting the dynamically
assigned space doesn't cause a segmentation
fault?

Because undefined behavior by definition can be anything at all. You
were lucky, nothing more.

I'd rather have said "you were unlucky".

--
-ed- get my email here: http://marreduspam.com/ad672570
The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
C-reference: http://www.dinkumware.com/manuals/reader.aspx?lib=c99
FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/

[Emmanuel Delahaye]

In 'comp.lang.c', tweak <xb**********@cox.net> wrote:

I have been messing around with buffers, and
I found it peculiar that the code below will
run without a segmentation fault.
May be it's correct, who knows ?
As far as I know, overwriting the allocated space
from a call to malloc() results in undefined
behavior.
Yes.
Any ideas why overwriting the dynamically
assigned space doesn't cause a segmentation
fault?
Why should do it ? An undefined behaviour in unpredictable. Anything may
happen, including a safe behaviour. Imagine you ask for 50 char. Some
implementation could give you the address of a 64 char block. You could write
at [50] to [63] safely.

The problem is that you don't know about the actual safe size. The C-language
only guarantees that the wanted size is safe. I know other implementations of
memory allocator (PSoS) where an additional parameter is used to return the
actual allocated size.
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <errno.h>

int
main(void)
{

char *ptr = NULL;
char buffer[256]; /* intentionally did not initialize */
int y = 0;

if ( ( ptr = malloc(1) ) == 0 ) {
Should be '== NULL' to preserve reader's mental health.
perror("malloc() problem");
exit(1);
exit (EXIT_FAILURE);

for portability.
}

for ( int i; i < 255; i++ )
Warning, This construct only works in C99.
buffer[i] = 'Z';

while ( (ptr[y] = buffer[y]) != '\0' )
Of course, you are overwriting the array pointed by ptr, but you know it
already.
y++;
Because 'buffer' was intentionally not initialized, there is no guarantee
that a 0 is present at [255].
(void)printf("ptr is: %s\n", ptr);
Can be anything.
free(ptr);

return 0;
}

--
-ed- get my email here: http://marreduspam.com/ad672570
The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
C-reference: http://www.dinkumware.com/manuals/reader.aspx?lib=c99
FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/

[Emmanuel Delahaye]

In 'comp.lang.c', "Vijay Kumar R Zanvar" <vi*****@globaledgesoft.com>
wrote:

F:\>splint overflow.c
Splint 3.0.1.6 --- 11 Feb 2002

overflow2.c: (in function main)
overflow2.c(15,18): Unrecognized identifier: NULL

Sounds that your Splint is badly configured. You must teach it where to find
the headers.

--
-ed- get my email here: http://marreduspam.com/ad672570
The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
C-reference: http://www.dinkumware.com/manuals/reader.aspx?lib=c99
FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/

[tweak]

Emmanuel Delahaye wrote:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <errno.h>

int
main(void)
{

char *ptr = NULL;
char buffer[256]; /* intentionally did not initialize */
int y = 0;

if ( ( ptr = malloc(1) ) == 0 ) {

Should be '== NULL' to preserve reader's mental health.

Correct. I was not being consistent.

perror("malloc() problem");
exit(1);

exit (EXIT_FAILURE);

for portability.

Now, this I am curious about. How is using EXIT_FAILURE
more portable?

}

for ( int i; i < 255; i++ )

Warning, This construct only works in C99.

This is a typo. It should be int i = 0;

buffer[i] = 'Z';

while ( (ptr[y] = buffer[y]) != '\0' )

Of course, you are overwriting the array pointed by ptr, but you know it
already.

y++;

Because 'buffer' was intentionally not initialized, there is no guarantee
that a 0 is present at [255].

Which is why I did not initialize it. I wanted buffer to contain
garbage. I threw in a bunch of Z's, so that I can search my registers
to see if they were overwritten with 0x5a. The condition was just there
to enable the while loop to insert my Z's.

The while can continue to run, which is another problem that my compiler
did not pick up on.

What methods or programs are available for auditing C code?

Thanks,

Brian

--
* Remove x's to send me mail *

[Emmanuel Delahaye]

In 'comp.lang.c', tweak <xb**********@cox.net> wrote:

exit(1);

exit (EXIT_FAILURE);

for portability.

Now, this I am curious about. How is using EXIT_FAILURE
more portable?

Returning values other than 0, EXIT_FAILURE or EXIT_SUCCESS to the system are
not guaranteed to work properly.

In your case, you return 1. Could be interpreted as the "self-destruct launch
command" by your system, who knows... Just in case, check your system
documentation...

Because 'buffer' was intentionally not initialized, there is no guarantee
that a 0 is present at [255].

Which is why I did not initialize it. I wanted buffer to contain
garbage. I threw in a bunch of Z's, so that I can search my registers
to see if they were overwritten with 0x5a. The condition was just there
to enable the while loop to insert my Z's.

The while can continue to run, which is another problem that my compiler
did not pick up on.

What methods or programs are available for auditing C code?

A real and long experience of the C language. Could be a profitable full part
job. Some automatic tools can help (Lint or the like), but the eyes of a
trained human are not easily replacable.

--
-ed- get my email here: http://marreduspam.com/ad672570
The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
C-reference: http://www.dinkumware.com/manuals/reader.aspx?lib=c99
FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/

[Keith Thompson]

tweak <xb**********@cox.net> writes:

Emmanuel Delahaye wrote:

[...]

exit(1);

exit (EXIT_FAILURE); for portability.

Now, this I am curious about. How is using EXIT_FAILURE
more portable?

As someone already pointed out, the only arguments to exit() that are
guaranteed to be meaningful are 0, EXIT_SUCCESS, and EXIT_FAILURE. 0
denotes success, but is not encessarily equal to EXIT_SUCCESS.

A concrete example: exit(1) in VMS causes the program to return a
status that indicates success (odd values indicate success, even
values indicate failure). (There's special code that maps exit(0) to
a success indication.)

for ( int i; i < 255; i++ )

Warning, This construct only works in C99.

This is a typo. It should be int i = 0;

Which only works in C99. C90 does not allow a declaration in a for loop.

In C99:

for (int i = 0; i < 255; i ++)

In C90:

int i;
...
for (i = 0; i < 255; i ++)

(which of course will also work in C99).

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Keith Thompson]

rl*@hoekstra-uitgeverij.nl (Richard Bos) writes:

tweak <xb**********@cox.net> wrote:

[...]

Also since malloc() returns a NULL pointer on failure,

No, it doesn't. It returns a null pointer. NULL is a macro, which
expands to a null pointer _constant_, and exists only in your source
code; a null pointer is an object, which exists during runtime.

A null pointer is a value.

the line that starts with if should read:

if ( ( ptr = malloc(1) ) == NULL ) {

to be consistent even though it's just a style thing.

There's nothing consistent about it. The original is just as good, just
as clear, and just as proper C. The only way in which this version could
be more, rather than just as, consistent, is if you've used NULL
everywhere else in your code; but that is consistency with _yourself_,
not with C. C does not distinguish between those two versions; both must
work equally well.

That was the point; he used NULL a few lines up, in the initialization
of ptr.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[tweak]

Keith Thompson wrote:

tweak <xb**********@cox.net> writes:

Emmanuel Delahaye wrote:
[...]

exit(1);

exit (EXIT_FAILURE); for portability.

Now, this I am curious about. How is using EXIT_FAILURE
more portable?

As someone already pointed out, the only arguments to exit() that are
guaranteed to be meaningful are 0, EXIT_SUCCESS, and EXIT_FAILURE. 0
denotes success, but is not encessarily equal to EXIT_SUCCESS.

A concrete example: exit(1) in VMS causes the program to return a
status that indicates success (odd values indicate success, even
values indicate failure). (There's special code that maps exit(0) to
a success indication.)

Thanks. I had originally coded it with abort(), which I do not
think is a part of ISO C99, so I replaced it with exit() for my
example. And I should have used EXIT_FAILURE.

This is gonna sound dumb. But what is VMS?

for ( int i; i < 255; i++ )

Warning, This construct only works in C99.

This is a typo. It should be int i = 0;

Which only works in C99. C90 does not allow a declaration in a for loop.

In C99:

for (int i = 0; i < 255; i ++)

In C90:

int i;
...
for (i = 0; i < 255; i ++)

(which of course will also work in C99).

Thanks for clearing this up for me.

Brian

P.S. I code as a hobby, not as a job, so I don't have the benefit
of working with this stuff every day.
--
* Remove x's to send me mail *

[Keith Thompson]

tweak <xb**********@cox.net> writes:
[...]

Thanks. I had originally coded it with abort(), which I do not
think is a part of ISO C99, so I replaced it with exit() for my
example. And I should have used EXIT_FAILURE.
abort() is part of ISO C (both C90 and C99), but it's more drastic
than exit().
This is gonna sound dumb. But what is VMS?

VMS is an operating system. Google "VMS" for more information.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Peter Nilsson]

"tweak" <xb**********@cox.net> wrote in message news:qtmHc.148$rr.78@fed1read02...

if ( ( ptr = malloc(1) ) == 0 ) {
perror("malloc() problem");

Since malloc is not required to set errno, this may well print messages like...

malloc() problem: no error

Generally, such messages tend to build distrust between end users and the programs they
use! ;)

--
Peter

[tweak]

Peter Nilsson wrote:

"tweak" <xb**********@cox.net> wrote in message news:qtmHc.148$rr.78@fed1read02...

if ( ( ptr = malloc(1) ) == 0 ) {
perror("malloc() problem");

Since malloc is not required to set errno, this may well print messages like...

malloc() problem: no error

Generally, such messages tend to build distrust between end users and the programs they
use! ;)

--
Peter

Two items:

1) What would be the preferred way to exit a failed malloc() call? I
will assume that would also include clean up code.

2) Can you write code that causes malloc() to fail? I am having trouble
doing this. I want to verify that my implementation does not set
errno.

Thanks,

Brian

P.S. I usually figure stuff out by breaking it.

--
* Remove x's to send me mail *

[Jens.Toerring]

tweak <xb**********@cox.net> wrote:

Two items: 1) What would be the preferred way to exit a failed malloc() call? I
will assume that would also include clean up code.
There's no prefered way, it depends solely on the application. If
your program can't continue without the memory it probably would
make sense to tell the user and exit. On the other hand, if the
memory isn't that necessary and there are other ways to do what
you want aborting the program would be overkill. And you may also
have situations where the problem appears during some sub-task of
the program and where you only may have to give up on running that
sub-task but not killing the whole program. E.g. if you write a
chess program and the user switches to a mode where the program
tries to play very clever you might run out of memory. And in this
case it might be nicer to tell the user that the program can't run
with this level and that it has to switch back to a level where
it needs less memory instead of killing the whole game.
2) Can you write code that causes malloc() to fail? I am having trouble
doing this. I want to verify that my implementation does not set
errno.

That can be difficult, depending on a lot of settings of the system
(well you should get there if you malloc() more memory than there
is address space...).
<OT>
On most UNIX-like systems you can set the maximum amount of memory a
process may use (see ulimit or limit, depending on your shell) and
that can really result in malloc() returning NULL.
</OT>
Regards, Jens
--
\ Jens Thoms Toerring ___ Je***********@physik.fu-berlin.de
\__________________________ http://www.toerring.de