8 posts / 0 new
Last post
jhexan jhexan's picture
Buffer Overflow (adjusted size)

Hi. Getting a lot of buffer overflow errors similar to:

Buffer overflow, array index of 'm_length' may be out of bounds. Array 'm_length' of size 11 (adjusted size 2) may use index value(s) 2..10

Code:
typedef unsigned char uint8_t;
typedef unsigned int uint32_t;
uint32_t m_length[NUM_COUNTERS];

void SetIndices(const EZChipSpecialCounters& specialCounters)
{
for (int i = 0; i {
SetIndex(i, specialCounters.counter[i].index);
m_length[i] = specialCounters.counter[i].length;
}
}

Another similar error:

Buffer overflow, array index of 'index' may be out of bounds. Array 'index' of size 2 (adjusted size 0) may use index value(s) 0.

Code:
uint32_t index[2];
index[0] = 0;

And finally:

Buffer overflow, array index of 'bios_data' may be out of bounds. Array 'bios_data' of size 64 (adjusted size 16) may use index value(s) 16..63

Code:
uint8_t bios_data[FLASH_IO_SIZE];
for (i = 0; i {
bios_data[i] = spi_reg_read(FDATA_OFFSET(i), FDATA_SIZE);
}

There doesn't seem to be anything wrong with the code above. Any ideas why these get picked up?

Thanks.

azukich azukich's picture
These "adjusted size" issues

These "adjusted size" issues tend to be associated with the values that are cast. If you don't see any casting anywhere then first check to see if you have any parse errors or build errors for that particular build.

jhexan jhexan's picture
Thanks for the reply. There

Thanks for the reply. There doesn't seem to be any casting done, and I'm not aware of any build/parse errors. The majority of these issues are "adjusted size 0" (which I'm not sure how they would occur).

zhegulev zhegulev's picture
I get these defects reported

I get these defects reported only if types uint8_t and uint32_t are not defined. Unfortunately if types are not defined we don't report anything to the parse_errors.log, but in some cases it means either missing include (see build.log) or missing macro definition. If there are no missing includes in the build.log try creating preprocessed file and see if typedef is there. If not try to check macros that guard these types.

To create a preprocessed file you can create a copy of your buildspec (small.out), remove all compile lines except for the one with your file and run:
kwbuildproject small.out -a -E -n -N -o prep_tables [other options you use]
You preprocessed file will be the .o file in prep_tables/obj

speri speri's picture
Hi , so I have a similar

Hi , so I have a similar issue as posted by jhexan - just that I have an array

uint32_t free_nodes[100]; and klocwork seems to adjust it to 25 for some reason and complains that the indexes 26 - 100 that are accessed may be out of bounds.

I do not see any build/parse errors and also uint32_t is defined in the types.h on the machine which I am running klocwork on.

Any other ideas what could be going on or how to get this resolved ?

zhegulev zhegulev's picture
Would you be able to create a

Would you be able to create a kwsupport archive?

kwsupport pack -f <path/file_with_the_defect> -o result.kwz <build.log>

this command will pack all files required to compile you source file.

mfrank mfrank's picture
We've discovered in our code

We've discovered in our code the root cause of these was that we were using anonymous unions. Although anonymous unions have well defined semantics in C++ and in C11, (and most compilers "do the right thing" with them) they are probably not well defined in C99, and thus probably a bad idea. So Klocwork was indeed giving us a false positive, but the "fix" led to better code.

We had something like:

struct foo {
int x;
union {
int y[2];
float z[2];
};
} bar;

and we were accessing bar.y[1], which Klocwork was giving as "adjusted size 0". So we have changed our code to:


struct foo {
int x;
union {
int y[2];
float z[2];
} u;
} bar;

which we access with bar.u.y[1].

zhegulev zhegulev's picture
Matthew, I tried your

Matthew,

I tried your example:


struct foo {
int x;
union {
int y[2];
float z[2];
};
} bar;

void test(){
bar.y[1] = 0;
bar.y[2] = 0;
}

And I've got only one defect here:

Buffer overflow, array index of 'y' may be out of bounds. Array 'y' of size 2 may use index value(s) 2

It is reported for bar.y[2]

Maybe I tried a wrong version. What version are you using?

Log in or register to post comments