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(a)gnumonks.org>
http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)