Overwriting Allocated Memory from malloc()

Discussion in 'C Programming' started by tweak, Jul 9, 2004.

  1. tweak

    tweak Guest

    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 = 'Z';

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

    return 0;
    }
     
    tweak, Jul 9, 2004
    #1
    1. Advertisements

  2. tweak

    Eric Amick Guest

    Because undefined behavior by definition can be anything at all. You
    were lucky, nothing more.
     
    Eric Amick, Jul 9, 2004
    #2
    1. Advertisements

  3. tweak

    Lewis Bowers Guest

    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.
     
    Lewis Bowers, Jul 9, 2004
    #3
  4. 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.




    <<Remove the del for email>>
     
    Barry Schwarz, Jul 9, 2004
    #4
  5. tweak

    tweak Guest

    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
     
    tweak, Jul 9, 2004
    #5
  6. lint may be helpful. See below.
    i is uninitialized. UB.


    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
     
    Vijay Kumar R Zanvar, Jul 9, 2004
    #6
  7. tweak

    tweak Guest

    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.

    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
     
    tweak, Jul 9, 2004
    #7
  8. tweak

    Richard Bos Guest

    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.
    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
     
    Richard Bos, Jul 9, 2004
    #8
  9. I'd rather have said "you were unlucky".
     
    Emmanuel Delahaye, Jul 9, 2004
    #9
  10. May be it's correct, who knows ?
    Yes.
    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.
    Should be '== NULL' to preserve reader's mental health.
    exit (EXIT_FAILURE);

    for portability.
    Warning, This construct only works in C99.


    Of course, you are overwriting the array pointed by ptr, but you know it
    already.
    Because 'buffer' was intentionally not initialized, there is no guarantee
    that a 0 is present at [255].
    Can be anything.
     
    Emmanuel Delahaye, Jul 9, 2004
    #10
  11. Sounds that your Splint is badly configured. You must teach it where to find
    the headers.
     
    Emmanuel Delahaye, Jul 9, 2004
    #11
  12. tweak

    tweak Guest

    Correct. I was not being consistent.
    Now, this I am curious about. How is using EXIT_FAILURE
    more portable?
    This is a typo. It should be int i = 0;


    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
     
    tweak, Jul 9, 2004
    #12
  13. 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...
    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.
     
    Emmanuel Delahaye, Jul 9, 2004
    #13
  14. 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.)
    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, Jul 9, 2004
    #14
  15. A null pointer is a value.
    That was the point; he used NULL a few lines up, in the initialization
    of ptr.
     
    Keith Thompson, Jul 9, 2004
    #15
  16. tweak

    tweak Guest

    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?
    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.
     
    tweak, Jul 10, 2004
    #16
  17. abort() is part of ISO C (both C90 and C99), but it's more drastic
    than exit().
    VMS is an operating system. Google "VMS" for more information.
     
    Keith Thompson, Jul 10, 2004
    #17
  18. 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 Nilsson, Jul 10, 2004
    #18
  19. tweak

    tweak Guest

    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.
     
    tweak, Jul 10, 2004
    #19
  20. 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.
    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.Toerring, Jul 10, 2004
    #20
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.