Stack corruption from set_system_infos

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.org
Thu Jan 7 09:19:30 UTC 2010


hi Zecke,

On Wed, Jan 06, 2010 at 07:59:21AM +0100, Holger Freyther wrote:
> On Thursday 31 December 2009 11:23:00 Harald Welte wrote:
> > Hi Zecke,
> 
> > > 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.
> 
> This was bullshit...
> 
> Here is the root cause:
> 
> For SI5 and SI6 we have to deal with the BS11 of having left the length field 
> out... What we are doing is:
> 
> char output[23];
> if (is_nano_bts) {
>     *output = len;
>     ++output;
> }
> 
> si6 = (struct si6*) output;
> memset(si6, padding, 23);
> 
> And one thing I have found as well, but it seems more like I'm wrong. All 
> data_len of the bitvector are one too big? Is that done on purpose?

no, that is an artefact from the 04.08 spec always claiming that an IE has
a certain length, but then icnluding the TAG, despite never sending the TAG
in front of the IE on the actual air interface.

> Patch 0001 and 0003 are of cosmetic nature, 0002 and 0004 seem to fix the stack 
> corruption my system is seeing.

Please apply them, they're fine.  In addition, we should probably remove the
++output from the generate_si, and have the RSL layer deal with it.
Specifically:
 * include the system_information_type_header in SI5 and SI6 data structures
 * make sure the buffers passed to generate_si are large enough to include
   the l2_plen, maybe even check at runtime to be sure
 * in the RSL layer (rsl_sacch_filling()), check the trx->bts->type and
   either drop the length (BS11) or keep it (all other BTS)

Thanks in advance,
	Harald

-- 
- 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