Hi Stefan, On Wed, Aug 19, 2015 at 04:13:24PM +0200, Stefan Schmidt wrote: > lbt and ackreq_default only accept 0or 1 as arguments which we did not > acount for so far. Testing invalid arguments and checking teh return > code uncovered this one. > > Signed-off-by: Stefan Schmidt <stefan@xxxxxxxxxxxxxxx> > --- > src/mac.c | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/src/mac.c b/src/mac.c > index 76db58f..26c6fc5 100644 > --- a/src/mac.c > +++ b/src/mac.c > @@ -175,6 +175,8 @@ static int handle_lbt_mode(struct nl802154_state *state, > mode = strtoul(argv[0], &end, 0); > if (*end != '\0') > return 1; > + if (mode != 0 && mode != 1) > + return 1; > > NLA_PUT_U8(msg, NL802154_ATTR_LBT_MODE, mode); > > @@ -202,6 +204,8 @@ static int handle_ackreq_default(struct nl802154_state *state, > ackreq = strtoul(argv[0], &end, 0); > if (*end != '\0') > return 1; > + if (ackreq != 0 && ackreq != 1) > + return 1; > range checks should be handled by kernelspace. Currently we do a "!!var" conversion there. Maybe we should change it there and accept "1" or "0". We should never handle "if a range is valid or not" inside userspace, otherwise other applications which talking to nl802154 can do a different handling then. - Alex -- To unsubscribe from this list: send the line "unsubscribe linux-wpan" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
