Wireshark-bugs: [Wireshark-bugs] [Bug 10646] rpc null calls incorrectly flagged as malformed
Comment # 6
on bug 10646
from Bill Meier
Before calling the sub-dissector for an rpc call/reply packet, the rpc
dissector currently does the following:
i = proto_tree_add_item(..., <sub-dissector-proto-id>, tvb, offset, -1, ...);
proto_item_add_subtree(...);
...
if (tvb_length_remaining(tvb, offset) == 0)
return TRUE; // nothing to do
<call sub-dissector(...,tvb, ...)>
However, an RPC call/reply "NULL" procedure, by definition, has no parameters.
so the [tvb, offset, -1] at the point of the proto_tree_add_item() above is of
zero length.
Replacing the -1 by 'tvb_length_remaining(tvb, offset)' in the
proto_tree_add_item() above fixes the bug since it appears that
proto_tree_add_item() will allow length to be 0.
This does seem a rather ugly fix and since I've not been involved in all the
stuff about zero-length tvb's (or use of tvb's with no data remaining) I don't
know if this is really considered valid.
I do note: it seems that the rpc sub-dissectors (e.g., nfs) are actually
expecting to be called (i.e., coded to handle) NULL procs with a tvb with
zero-remaining bytes, but the rpc dissector does not call the sub-dissector if
there's no remaining data.
I've uploaded the above fix to Gerrit for for further review and discussion.
see: https://code.wireshark.org/review/#/c/5700/
You are receiving this mail because:
- You are watching all bug changes.
