Comment # 3
on bug 12119
from Diederik de Groot
(In reply to Michael Mann from comment #2)
> 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)
If more or other checks are required, that would not be so difficult to do, all
of the packet dissector source is generated, so it would only have to be added
in 1-2 places. I just need to know what checks you would like me to perform. It
has been a little while since i wrote this version of the dissector and am not
100% sure what tap / ptv and tvb's are in this context :-)
Checking the existence of the cursor pointer would be the first obvious step,
and i don't see anything wrong with adding it. If you can give me some examples
of the checks you would like to be added, I/we can adapt the python (generator)
code where needed to make that happen.
You are receiving this mail because:
- You are watching all bug changes.
