AIX 5.3 vs Solaris 5.10 - C strcat implementation

Question

Does anyone have any idea of why this could happen?

I have a C program in AIX 5.3, I've been asked to run it on a SPARC Solaris 10 machine, but when I did it, I noticed there was a buffer overflow with one of the many reckless strcat uses. My goal is not to sanitize the code but to provide a concrete and well founded answer of why does this overflow happens on Solaris and not on AIX being the exact same bad coded program.

I've been reading a bit about if this could be caused by:

1. endianess diffs between AIX and Solaris.

2. Execution of the strcat function (AIX copies right to left and Solaris left to right) but I haven't been able to find any documentation on this.

3. Plain and simple luck that this issue doesn't occur on AIX.

Any light you could shed on this is highly appreciated.

EDIT: could this be avoided with the noexec_user_stack flag on solaris?

EDIT 2: Does anyone have any info on the way both OSes do the actual byte copying? in a situation like the option 2 above?

EDIT 3: Here's the chunk of code:

/*global*/
char bufferA[101];
/*inside function*/
bufferA[0]='\0';
strcpy(bufferA,"1");
if (atoi(something)==0) {
strcat(bufferA,pieces_of_data);
count ++ ;
}

obviously theres more of it but this is the only part where bufferA is being used, and there 2 variables declared global after bufferA that become corrupted with the last part of the last string appended to bufferA.

As i said before, if i change the declaration from 101 to 201 the corruption does not occur.

EDIT 4: does anyone know anything about the -misalign and -misalign2 compiler options on solaris? could there be any light with these options? Actually a better question would be: is there any difference between AIX powerPC and Solaris SPARC regarding alignment? altough this is probably a question for serverfault but please share if you know something.

Answer 1

It was either (bad?) luck or, perhaps, an artefact of slightly different memory management systems, with more space being allocated on AIX than on Solaris.

It depends, in part, on how egregious the overflows are. If they are a couple of bytes out of bounds and if AIX habitually allocates, say, 32 byte minimum blocks where Solaris allocates 16 byte minimum blocks, then there is more room for error without damage on AIX than on Solaris. Even so, if you get it wrong in the wrong context, AIX should also have the problem - you can regard yourself as unlucky not to have observed the problem on AIX for, as you say, it surely occurs there just as much as it does on Solaris if the source code you're compiling is the same.

Further investigation shows:

• For 32-bit compilations, AIX 5.3 allocates a multiple of 16 bytes per allocation, just like Solaris.
• For 64-bit compilations, AIX 5.3 allocates a multiple of 32 bytes per allocation; this is also the same as Solaris.

However, if you changed between 32-bit and 64-bit builds between AIX and Solaris, this might still be the source of your problem.

Whatever the answer, now you are aware of it, fix it for both platforms with one set of changes. You treat every such exposed bug with gratitude; at any time, a change on the original platform may reveal the problem - leading to major problems with dissatisfied customers.

(Oh, I think both SPARC and PPC are big-endian machines; it is Intel that is little-endian and different from the rest of the world.)

---

Test code - with deliberate, intentional leak

#include <stdlib.h>
#include <stdio.h>
int main(void)
{
    int sz ;
    char *buffer;
    for (sz = 1; sz < 1025; sz *= 2)
    {
        buffer = malloc(sz);
        printf("0x%08lX\n", (unsigned long)buffer);
    }   
    return 0;
} 

Answer 2

I'm not sure if this counts as an answer or not, but a quick-and-dirty fix might be to search-and-replace all instances of malloc in the code with workaround_malloc, and implement the latter as a call to malloc(size+100).. :-)

Answer 3

If it happens on one platform, it happens on the other. You were just lucky that the memory layout on the one platform caused the error to manifest.

It is undefined behavior.

If you have a steaming mound of unguarded strcpy/cats littering your code, fix the code. Don't blame the platform. Blame the author.

Valgrind is your friend.

Answer 4

It's probably a processor dependent manifestation of the bug. The padding and alignment of data are both usually determined by the characteristics of the target processor. Extra padding bytes may be hiding the error on one target, while on another target there are fewer padding bytes.

It could also have to do with the actual data that strcat is being passed being different. For instance if part of the string that it was building were to consist of the name of the OS, processor, or the path of a system file.

It could also be that the strings were allocated with a size based on either a header constant or a sizeof that is different for the different targets, so your actual buffer is smaller.

One thing I might try would be to have the compilers produce preprocessed versions of the source files for each target and diff those. They will probably differ a lot in the initial header code, but should be mostly similar near the end where your code is. See if any suspicious differences are in that code. Sadly sizeof will not be replaced by numbers here, but macro constants will be.

Answer 5

Here is how you can use Solaris Studio debugger to find memory access/usage errors:

1: Download studio
  http://www.oracle.com/technetwork/server-storage/solarisstudio/overview/index.html
2: Install it
  Uncompress/Extract the downloaded file somewhere in your disk
  Run the installer
3: Recompile your program with debugging on
  $ PATH=$PATH:/opt/<studio-installation-directory>/bin
  $ cc -g program.c
4: Launch your program under debugger control
  $ dbx program
5: Enable run time checking
  (dbx) check -all
  access checking - ON
  memuse checking - ON
6: Run your program
  (dbx) run
7: Watch all the error messages
  ...