I recentely talked with another 6lowpan linux developer about an ugly behaviour of at86rf2xx transceivers and I told him I could break many of nodes which use them because nobody really care about that while programming.
The issue is that the len byte inside the PHR will not filtered by the at86rf2xx transceivers, so the length could be above 127. Also remember this can happen when the CRC is still correct. So I can mostly overwrite some stack space, when the buffer is allocated on stack at first.
Most datasheets doesn't say anything what they filter on PHR or not.
In conclusion we introduce inside the Linux kernel  and all drivers will check the length field when receiving at first.
In case of at86rf230 driver we check the len field at first, if invalid then we read out the full frame buffer (interesting for monitor interfaces and mac802154/etc should filter them correctly anyway if it's invalid), just avoid copying above 127 because array boundaries. See .
btw: We read also the full framebuffer always because the RX_SAFE_MODE functionality from at86rf2xx transceivers. But then we check on a valid length field.
The developer told me to tell that RIOT, so I just want to leave a note here and I don't know if RIOT does filtering on that or not.
 http://lxr.free-electrons.com/source/include/linux/ieee802154.h#L263  http://lxr.free-electrons.com/source/drivers/net/ieee802154/at86rf230.c#L704