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)