This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Harald Welte laforge at gnumonks.orgHi 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)