Comment # 4
on bug 9256
from Evan Huus
So this was a regression caused by r52311 which fixed bug #9212. Specifically,
the breaking change was the change to the ITERATOR_VALID macro on line 77 of
packet-ieee80211-radiotap-iter.c. Reverting just that one line fixes this bug.
However, reverting that line also reintroduces one small part of bug #9212 -
with the capture from that bug, valgrind produces:
==32652== Invalid read of size 1
==32652== at 0x67D675B: ieee80211_radiotap_iterator_init
(packet-ieee80211-radiotap-iter.c:152)
==32652== by 0x67D6CD2: dissect_radiotap (packet-ieee80211-radiotap.c:1038)
==32652== by 0x648D2D3: call_dissector_through_handle (packet.c:492)
==32652== by 0x648D98F: call_dissector_work (packet.c:586)
==32652== by 0x648E24B: dissector_try_uint_new (packet.c:1017)
==32652== by 0x648E2A6: dissector_try_uint (packet.c:1043)
==32652== by 0x671AA22: dissect_frame (packet-frame.c:488)
==32652== by 0x648D2D3: call_dissector_through_handle (packet.c:492)
==32652== by 0x648D98F: call_dissector_work (packet.c:586)
==32652== by 0x648F511: call_dissector_with_data (packet.c:2105)
==32652== by 0x648F953: dissect_packet (packet.c:430)
==32652== by 0x64822DD: epan_dissect_run_with_taps (epan.c:277)
==32652== Address 0x106b79ef is 0 bytes after a block of size 47 alloc'd
==32652== at 0x4C2A2DB: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==32652== by 0x94F2DC0: g_malloc (gmem.c:104)
==32652== by 0x6EFBBDF: wmem_simple_alloc (wmem_allocator_simple.c:51)
==32652== by 0x64BD265: tvb_memdup (tvbuff.c:774)
==32652== by 0x67D6CA6: dissect_radiotap (packet-ieee80211-radiotap.c:1034)
==32652== by 0x648D2D3: call_dissector_through_handle (packet.c:492)
==32652== by 0x648D98F: call_dissector_work (packet.c:586)
==32652== by 0x648E24B: dissector_try_uint_new (packet.c:1017)
==32652== by 0x648E2A6: dissector_try_uint (packet.c:1043)
==32652== by 0x671AA22: dissect_frame (packet-frame.c:488)
==32652== by 0x648D2D3: call_dissector_through_handle (packet.c:492)
==32652== by 0x648D98F: call_dissector_work (packet.c:586)
Perhaps someone more familiar with the protocol could figure out the right way
to fix that without breaking proper dissection? The capture from this bug does
not produce such an error, even with the change reverted.
You are receiving this mail because:
- You are watching all bug changes.