[riot-devel] at86rf2xx and PHR filtering
thomas.eichinger at fu-berlin.de
Mon Apr 4 16:26:06 CEST 2016
thanks for pointing out and letting us know about a possible
vulnerability related to the length field. It rose attention to the fact
that we checked it in past versions of the driver but missed it at some
point in transition. With  we should respect this again.
Regarding your example on state transition below, for the driver getting
stuck in the assertion loop the transceiver would already have to be in
RX_AACK_ON state before to change into RX_AACK_BUSY. The MCU's call of
at86rf2xx_set_state(foo, RX_AACK_ON) would then already return in the
fourth line of this function .
As far as I can see the situation pointed out by you should be avoided
with this for most situations.
Looking at the code now we might should exchange the order of this check
with the loop waiting for busy states though to catch the case the
transceiver is busy receiving and a call of at86rf2xx_set_state(foo,
On 1 Apr 2016, at 7:24 ART(-0300), Alexander Aring wrote:
> I looked now in RIOT code .
> So they will call at86rf2xx_set_state(at86rf2xx_t *dev, uint8_t state)
> with state as RX_AACK_ON, but at the end they call:
> _set_state(at86rf2xx_t *dev, uint8_t state)
> with RX_AACK_ON, so it could be that RIOT has this behaviour:
> MCU -> at86rf2xx_set_state(foo, RX_AACK_ON)
> at86rf2xx -> going into RX_AACK_ON
> at86rf2xx -> detected SFD, going into RX_AACK_BUSY
> MCU -> _set_state(foo, RX_AACK_ON)
> MCU -> while (at86rf2xx_get_status(dev) != state) -> stucks
> inside this loop
> at86rf2xx -> receiving done, going into RX_AACK_ON
> MCU -> while (at86rf2xx_get_status(dev) != state) -> loop
> The stucking inside the loop for assertion is here a possible case
> is bad. But okay it's unlikely I also get such issues only when I make
> really big traffic.
> - Alex
> devel mailing list
> devel at riot-os.org
More information about the devel