Wireshark-bugs: [Wireshark-bugs] [Bug 9612] Dissector of AMQP 1.0

Date: Thu, 23 Jan 2014 09:07:53 +0000

Comment # 18 on bug 9612 from
(In reply to comment #17)
> Created attachment 12490 [details]
> Fuzz file triggering valgrind
> 
> The attached capture file produces a few minor errors when run under
> valgrind (with ./tools/valgrind-wireshark.sh).
> 
> I took a quick look but it wasn't immediately obvious what the problem was.
> Some stack value somewhere isn't getting initialized.

I suspect valgrind is wrong here. Trying to locate the potential issue, frame
19 caused it, and "offset" variable in get_amqp_1_0_type_formatter method with
BT (code lines dont 100% match):

==6003==    at 0x638A10E: get_amqp_1_0_value_formatter (packet-amqp.c:6722)
==6003==    by 0x638A424: get_amqp_1_0_type_value_formatter
(packet-amqp.c:10421)
==6003==    by 0x638ADC8: dissect_amqp_1_0_frame (packet-amqp.c:6935)
==6003==    by 0x6978C45: tcp_dissect_pdus (packet-tcp.c:2291)
==6003==    by 0x638D159: dissect_amqp (packet-amqp.c:2796)
==6003==    by 0x6307613: call_dissector_through_handle (packet.c:582)
==6003==    by 0x6307EF4: call_dissector_work (packet.c:669)
==6003==    by 0x630855B: dissector_try_uint_new (packet.c:1100)
==6003==    by 0x6978F8D: decode_tcp_ports (packet-tcp.c:3921)
==6003==    by 0x69792FE: process_tcp_payload (packet-tcp.c:3980)
==6003==    by 0x69798F6: dissect_tcp_payload (packet-tcp.c:1805)
==6003==    by 0x697B58E: dissect_tcp (packet-tcp.c:4831)
==6003==  Uninitialised value was created by a stack allocation
==6003==    at 0x6389900: get_amqp_1_0_value_formatter (packet-amqp.c:10193)

Adding some printf("%d\n", offset) commands lead to observation that:
- printf at beginning of get_amqp_1_0_type_formatter prints the valgrind
warning
- printf in get_amqp_1_0_type_value_formatter just before calling
get_amqp_1_0_type_formatter does _not_ print the warning
- neither so printing offset, type_length_size and bound just before
AMQP_INCREMENT in the same method

So, valgrind complains of unitialized "offset" variable, that is apparently set
properly just before calling the method.

I run valgrind against several other AMQP 1.0 tcpdumps I have, and no issue
found.

I noticed valgrind detected some (in)directly loss bytes (i.e. a sort of memory
leak), but none of them is AMQP dissector relevant.


Having written that, I take the valgrind output as not relevant to (an issue
with) AMQP 1.0 dissector. Please let me know if I should investigate further.


You are receiving this mail because:
  • You are watching all bug changes.