Michael Mann
changed
bug 12119
Comment # 2
on bug 12119
from Michael Mann
The issue is in packet 176 when handle_UpdateCapabilitiesV3Message gets a very
large value for one of its (many) loops. The ptvcursor API doesn't throw an
exception if the offset is bigger than the tvb if there is no tree (which there
obviously isn't on first pass), which leads to a (seemingly infinite) loop.
The dissector doesn't use column or expert APIs within its opcode handling, but
does populate tap data, so I'm not sure if the proposed fix
(https://code.wireshark.org/review/14653) of tree checking is a good idea.
Seems better than having to add sanity checks for all of the loops that are in
the dissector (or changing ptvcursor API to throw exceptions)
You are receiving this mail because:
- You are watching all bug changes.