Wireshark-bugs: [Wireshark-bugs] [Bug 10885] Crash when use Telephony / Voip calls

Date: Wed, 11 Mar 2015 02:31:22 +0000

changed bug 10885


What Removed Added
CC   [email protected]

Comment # 3 on bug 10885 from
Valgrind says this (amongst other complaints):

~~~
==9624== Conditional jump or move depends on uninitialised value(s)
==9624==    at 0x4E799C: packet_list_get_value (packet_list_store.c:377)
==9624==    by 0x39AC835574: gtk_tree_model_get_valist (in
/usr/lib64/libgtk-x11-2.0.so.0.2400.25)
==9624==    by 0x39AC8358A8: gtk_tree_model_get (in
/usr/lib64/libgtk-x11-2.0.so.0.2400.25)
==9624==    by 0x453FCB: packet_list_get_record (packet_list.c:791)
==9624==    by 0x456664: packet_list_get_row_data (packet_list.c:1235)
==9624==    by 0x523A07: insert_to_graph_t38 (voip_calls.c:433)
==9624==    by 0x523A07: t38_packet (voip_calls.c:976)
==9624==    by 0x65294FE: tap_push_tapped_queue (tap.c:331)
==9624==    by 0x64F9FCB: epan_dissect_run_with_taps (epan.c:344)
==9624==    by 0x42A8AE: retap_packet (file.c:2338)
==9624==    by 0x42E23D: process_specified_records.constprop.14 (file.c:2308)
==9624==    by 0x42E3E2: cf_retap_packets (file.c:2382)
==9624==    by 0x4AD895: voip_calls_dlg_init_taps (voip_calls_dlg.c:919)
==9624== 
21:43:19          Crit packet_list_get_value: assertion 'iter->stamp ==
packet_list->stamp' failed

(lt-wireshark-gtk:9624): GLib-GObject-WARNING **: gtype.c:4221: type id '0' is
invalid

(lt-wireshark-gtk:9624): GLib-GObject-WARNING **: can't peek value table for
type '<invalid>' which is not currently referenced
==9624== Invalid read of size 8
==9624==    at 0x39AC835582: gtk_tree_model_get_valist (in
/usr/lib64/libgtk-x11-2.0.so.0.2400.25)
==9624==    by 0x39AC8358A8: gtk_tree_model_get (in
/usr/lib64/libgtk-x11-2.0.so.0.2400.25)
==9624==    by 0x453FCB: packet_list_get_record (packet_list.c:791)
==9624==    by 0x456664: packet_list_get_row_data (packet_list.c:1235)
==9624==    by 0x523A07: insert_to_graph_t38 (voip_calls.c:433)
==9624==    by 0x523A07: t38_packet (voip_calls.c:976)
==9624==    by 0x65294FE: tap_push_tapped_queue (tap.c:331)
==9624==    by 0x64F9FCB: epan_dissect_run_with_taps (epan.c:344)
==9624==    by 0x42A8AE: retap_packet (file.c:2338)
==9624==    by 0x42E23D: process_specified_records.constprop.14 (file.c:2308)
==9624==    by 0x42E3E2: cf_retap_packets (file.c:2382)
==9624==    by 0x4AD895: voip_calls_dlg_init_taps (voip_calls_dlg.c:919)
==9624==    by 0x39A1E0FD34: g_closure_invoke (in
/usr/lib64/libgobject-2.0.so.0.4200.1)
==9624==  Address 0x30 is not stack'd, malloc'd or (recently) free'd
==9624== 
==9624== 
==9624== Process terminating with default action of signal 11 (SIGSEGV)
==9624==  Access not within mapped region at address 0x30
==9624==    at 0x39AC835582: gtk_tree_model_get_valist (in
/usr/lib64/libgtk-x11-2.0.so.0.2400.25)
==9624==    by 0x39AC8358A8: gtk_tree_model_get (in
/usr/lib64/libgtk-x11-2.0.so.0.2400.25)
==9624==    by 0x453FCB: packet_list_get_record (packet_list.c:791)
==9624==    by 0x456664: packet_list_get_row_data (packet_list.c:1235)
==9624==    by 0x523A07: insert_to_graph_t38 (voip_calls.c:433)
==9624==    by 0x523A07: t38_packet (voip_calls.c:976)
==9624==    by 0x65294FE: tap_push_tapped_queue (tap.c:331)
==9624==    by 0x64F9FCB: epan_dissect_run_with_taps (epan.c:344)
==9624==    by 0x42A8AE: retap_packet (file.c:2338)
==9624==    by 0x42E23D: process_specified_records.constprop.14 (file.c:2308)
==9624==    by 0x42E3E2: cf_retap_packets (file.c:2382)
==9624==    by 0x4AD895: voip_calls_dlg_init_taps (voip_calls_dlg.c:919)
==9624==    by 0x39A1E0FD34: g_closure_invoke (in
/usr/lib64/libgobject-2.0.so.0.4200.1)
~~~

The basic problem is that the T.38 dissector is passing a frame-number of 0 to
its tap (in t38_info->frame_num_first_t4_data) which then causes heartburn in
packet_list_get_row_data() and below.

An assertion is probably appropriate here:

~~~
--- a/ui/gtk/packet_list.c
+++ b/ui/gtk/packet_list.c
@@ -1228,6 +1228,7 @@ packet_list_get_row_data(gint row)
     GtkTreeIter iter;
     frame_data *fdata;

+    g_assert(row > 0);
     gtk_tree_path_append_index(path, row-1);
     gtk_tree_model_get_iter(GTK_TREE_MODEL(packetlist), &iter, path);

~~~

Except for that minor detail that the row number could come from a dissector
(in this case via a tap).  Hmmm.  Too bad we can except out of taps.

This avoids the crash:

~~~
--- a/ui/voip_calls.c
+++ b/ui/voip_calls.c
@@ -973,6 +973,7 @@ t38_packet(void *tap_offset_ptr, packet_info *pinfo,
epan_dissect_t *edt, const
                 frame_label = g_strdup_printf("t4-non-ecm-data:%s", tmp_str1);
                 comment     = g_strdup_printf("t38:t4-non-ecm-data:%s
Duration: %.2fs %s",
                         tmp_str1, duration, t38_info->desc_comment );
+        if (t38_info->frame_num_first_t4_data > 0)
                 insert_to_graph_t38(tapinfo, pinfo, edt, frame_label, comment,
                         (guint16)conv_num, &(pinfo->src), &(pinfo->dst),
                         line_style, t38_info->frame_num_first_t4_data);
~~~

But obviously doesn't solve the root cause.  I looked around the T.38 dissector
a bit and it's at least possible the root cause is that evil nasty global
variable p_t38_conv_info.  Or maybe it's just a bug but following the logic
seemed a bit much for this evening...


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