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 Holger,
On Thu, Jan 02, 2014 at 08:35:54PM +0100, Holger Hans Peter Freyther wrote:
> osmo_rsl2sitype takes an uint8_t but makes no range checking, same
> goes for osmo_sitype2rsl.
>
> I plan to apply the below patch for osmo-bts.
I see no problem with that.
> This would resolve the last open Coverity report for osmo-bts. It
> would be nice if we could add range checking to osmo_rsl2sitype or
> check it in common/rsl.c of osmo-bts.
The osmo_rsl2sitype(uint8_5 rsl_si) function is using the rsl_si as
index into the rsl2sitype[256] array, so it cannot cause any array out
of bounds access, from what I can tell.
If we add range checking, then we would also have to specify an error
return code that would express the error from having occurred. So far,
SYSINFO_TYPE_NONE is defined as zero, i.e. will be returned for every
value between _MAX_SYSINFO_TYPE and 265.
As for osmo_sitype2rsl: Yes, indeed, if you pass a value outside the
enum osmo_sysinfo_type into the function, we may index sitype2rsl[] out
of bounds. The question is what to return? RSL of course has no
definition for a RSL_SYSTEM_INFO_INVALID or the like. So unless we
change the function prototype to return an integer type, we cannot
return -1...
Regards,
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)