Comment # 21
on bug 8111
from Martin Kaiser
(In reply to comment #14)
> The ideas look good to me, but we can't rely on the protocol giving us the
> total expected length before we get segments (DTLS does this, but not all
> might).
>
> There should likely be another check in fragment_set_tot_len that
> invalidates existing fragments or throws a dissector bug or something if we
> try to set a length while we already have fragments beyond it. This would
> also save us having to care about the call order in the DTLS dissector.
>
> Thoughts?
It turned out that changing the DTLS call order is enough to prevent the
reported crash. As many duplicates keep coming up, I committed this change in
r46739 to save us from closing another bunch of bugs.
As for the underlying problem, I believe this is what happens
fragments with key.id 1
...
we have all fragments and set FD_DEFRAGMENTED
call to frag_set_tot_len() sets the length to a stupidly large value
(fd_head->data_len is larger than the amount of data in fd_head->data)
another fragment with key.id 1
check for duplicate -> crash when we read beyond fd_head->data
What should happen when frag_set_tot_len() is called after the packet was
reassembled (and we know the actual length)? I'd assume we should not be
allowed to set a length larger than the computed length. If we set a smaller
length, we'd have to invalidate some fragments...
(I'm away from the keyboard for some days and won't be able to progress this
for now)
You are receiving this mail because:
- You are watching all bug changes.