On Thu, Sep 11, 2014 at 11:09:50AM +0200, Alexander Aring wrote: > Hi Martin, > > On Thu, Sep 11, 2014 at 10:53:53AM +0200, Alexander Aring wrote: > ... > > > > I know this issue and we should not do that in this way. > > > > Why? > > > > Because this works only for fragmentation with IPHC, for example if we > > support mesh or Broadcast or HC1 compression. We should call after > > successfully reassembled "means lowpan_frag_rcv returns 1" the lowpan_rcv again. > > So this is a recursion and we don't should use recursion to much, but it > > should only be one recursion, so I think that's okay. :-) > > > > I reconsider about that, this is not okay. A attacker can send data to > occur this stack overflow... > > We need another solution for this. Maybe your current one, but handling > fragmentation at the beginning and then evaulate dispatch values. > I look more in RFC 4944, it seems that mesh and BC0 and MESH always fits into a single fragmentation... but they don't say anything about max value and if we have encryption on... I am not sure now if there is a case where this can happen or not. Simple -> check fragmentation if fragmentation then goahead until it's reassembled. After reassembled check for all other dispatch values. This should be sure that we handle all packets if fragmented or not. - Alex -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
