Wireshark · Wireshark-bugs: [Wireshark-bugs] [Bug 11134] New: CORBA dissectors show malformed packet errors for void replies

[bugzilla-daemon@xxxxxxxxxxxxx]

Bug ID	11134
Summary	CORBA dissectors show malformed packet errors for void replies
Product	Wireshark
Version	1.12.4
Hardware	x86
OS	Windows 7
Status	UNCONFIRMED
Severity	Normal
Priority	Low
Component	Dissection engine (libwireshark)
Assignee	bugzilla-admin@wireshark.org
Reporter	Andy.Ling@quantel.com

Build Information:
Version 1.12.4 (Git Rev Unknown from unknown)

Copyright 1998-2015 Gerald Combs <gerald@wireshark.org> and contributors.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Compiled (32-bit) with GTK+ 2.24.23, with Cairo 1.10.2, with Pango 1.34.0, with
GLib 2.38.0, with WinPcap (4_1_3), with libz 1.2.5, with SMI 0.4.8, with c-ares
1.9.1, with Lua 5.2, without Python, with GnuTLS 3.2.15, with Gcrypt 1.6.2,
with
MIT Kerberos, with GeoIP, with PortAudio V19-devel (built Apr 21 2015), with
AirPcap.

Running on 64-bit Windows 7 Service Pack 1, build 7601, with WinPcap version
4.1.3 (packet.dll version 4.1.0.2980), based on libpcap version 1.0 branch
1_0_rel0b (20091008), GnuTLS 3.2.15, Gcrypt 1.6.2, without AirPcap.
Intel(R) Core(TM)2 Quad CPU    Q6700  @ 2.66GHz, with 8061MB of physical
memory.


Built using Microsoft Visual C++ 12.0 build 31101

--
I created a CORBA dissector from an IDL file using the idl2wrs script. This
compiles and runs, but generates "Malformed packet" errors for all replies with
no data.

The code that is causing this is in proto.c and tvbuff.c. The call stack starts
in the dissector.

start_dissecting -> proto_tree_add_item -> proto_tree_add_item_new ->
get_hfi_length -> tvb_ensure_captured_length_remaining


The comment in get_hfi_length says

     * We allow FT_PROTOCOLs to be zero-length -
     * for example, an ONC RPC NULL procedure has
     * neither arguments nor reply, so the
     * payload for that protocol is empty.

But the comment in tvb_ensure_captured_length_remaining says

        /*
         * This routine ensures there's at least one byte available.
         * There aren't any bytes available, so throw the appropriate
         * exception.
         */

So when there is no data in a reply an exception gets thrown causing the error.

In a previous version of proto.c there was a specific case clause for
FT_PROTOCOL that called tvb_length_remaining instead. This doesn't throw an
exception for a length of zero.

So get_hfi_length needs changing to either have a specific clause for
FT_PROTOCOL that doesn't throw for zero length or the existing call needs
changing to a call that doesn't throw (e.g. tvb_captured_length_remaining)

---

      You are receiving this mail because:

• You are watching all bug changes.