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