Stack corruption from set_system_infos

Harald Welte laforge at gnumonks.org
Thu Dec 31 11:23:00 CET 2009


Hi Zecke,

On Thu, Dec 31, 2009 at 06:12:31AM +0100, Holger Freyther wrote:

> I have a stack corruption due the above method and here is my analysis of the 
> problem...

thanks for your analysis.

> set_system_infos is having a u_int8_t array with 23 bytes on the stack and is 
> asking to generate system infos into this array...
> 
> Now what happens is:
> 	1.) some system information types structs are already bigger
>              than the 23 bytes...

why are they?  How can that be?  How can a SI message be larger than the
physical limitation of the MAC-Block?  This sounds like the root cause
of the problem to me.

> I would like to fix it like this:
> 	1.) Turn bitvec_spare_padding to return void

makes sense. after all, the caller already specifies the number of bits
up to which he wants the data to be padded.

> 	2.) In the rest_octets_siX method return the bit_vec.data_len

makes also sense to me.

> 	3.) Change the generate_siX to return the sizeof the struct
>             + return value of the rest_octets_siX instead of the fixed
>              MACBLOCK_LEN (23)
>         4.) always use this rc value instead of the size of the buffer...
>             (due to 1. of the above we set truncated values as well) 

also fine with me.

> do you have a better idea? would you just increase the buffer size?

as indicated above, the root cause might well be something else.  Nevertheless,
your suggested improvements are valid and correct.
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)




More information about the OpenBSC mailing list