It was found that Wireshark crashes when processing (with "tshark -nr genbroad.snoop") a sample file from the Wireshark wiki page:
wget 'http://wiki.wireshark.org/SampleCaptures?action=AttachFile&do=get&target=genbroad.snoop' -O genbroad.snoop
* crash reason: strlen() called on invalid pointer (value 0x56998680 == 1452902016)
* the function set_dnet_address at packet-dec-dnart.c:355
* it is called 4 times
* the 2nd time is the one when the value is set
* the variable is called addr in the context of /epan/dissectors/packet-dec-dnart.c:357, function set_dnet_address
* the variable is called pinfo->src->data in the upper frames
* in this function, this macro modifies the value:
SET_ADDRESS(paddr_tgt, AT_STRINGZ, 1,
* it should set paddr_tgt->data = addr, but the value gets garbled by the ctlq instruction:
|0x7ffff4d85522 dnet_address+50> callq 0x7ffff4b0d4b0 <wmem_strdup@plt>
|0x7ffff4d85527 dnet_address+55> cltq
This issue was discovered by Martin Žember of Red Hat.
Created wireshark tracking bugs for this issue:
Affects: fedora-all [bug 1219410]
This bug is due to a failure by the epan/dissectors/packet-dec-dnart.c dissector to include the <epan/wmem/wmem.h> header to properly declare the wmem_strdup() routine as returning a pointer, so, on LP64 platforms, its 64-bit pointer result gets shortened to an int and then widened back to a pointer.
This bug should not exist in Wireshark 1.12.x, for all values of x, as the change that introduced the call to wmem_strdup() in packet-dec-dnart.c also added an include of <epan/wmem/wmem.h>.
However, it *does* exist in 1.10.x, for at least some values of x, as, when the change in question was backported, the include was *not* added.
I have checked in a change to fix this:
That fix, along with
which is a fix for *another* problem revealed by compiling with -Werror (-Werror is your friend!), and possibly other fixes I check in as I fix more -Werror-detected problems, should be in the next 1.10.x Wireshark release, which should be 1.10.15. It has not yet been scheduled.
If you want to pick up individual fixes, go ahead.
(In reply to Guy Harris from comment #3)
> However, it *does* exist in 1.10.x, for at least some values of x
In particular, for x >= 12.
This issue has been addressed in the following products:
Red Hat Enterprise Linux 7
Via RHSA-2015:2393 https://rhn.redhat.com/errata/RHSA-2015-2393.html