Not sure if I am answering your question, and maybe you still consider this a security hole, but the lengths are checked in different places depending on the packet being received. For advertising channel packets, the lower-layer routines (ones that get called before the packet is handed to the link layer task) do length checking to make sure that the packet length matches the type of packet being sent. It is possible for memory to get corrupted between the check and handing it to the link layer task but not sure that is what you are concerned with.
Regarding data channel packets, I would have to go through the code to see exactly which length checks are made but it could be that the only length check made is one where the number of bytes pulled from the chip matches the value in the received data. Note that control packets are checked to make sure they are the appropriate length for that type of control frame. To make a long story short, the length checks should be done before the packet gets handed to the link layer task. > On Aug 24, 2016, at 3:04 PM, Tim Hutt <[email protected]> wrote: > > Hi, > > I've been looking through the code for ble_ll_rx_pkt_in(), and I can't see > anywhere where the length of `rxbuf` (`m->om_data`) is checked. The value > seems to be available in `m->om_len` but isn't read anywhere. Subsequent > functions just seem to assume that a packet is as large as it should be. > > Assuming I haven't misread the code, isn't that a huge security issue? > > Cheers, > > Tim
