Wireshark-bugs: [Wireshark-bugs] [Bug 10646] rpc null calls incorrectly flagged as malformed

Date: Wed, 10 Dec 2014 07:05:16 +0000

Comment # 6 on bug 10646 from
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.