Wireshark-bugs: [Wireshark-bugs] [Bug 12645] Buildbot crash output: fuzz-2016-07-22-23688.pcap
Date Index · Thread Index · Other Months · All Mailing Lists
Date Prev · Date Next · Thread Prev · Thread Next
From: bugzilla-daemon@xxxxxxxxxxxxx
Date: Sun, 24 Jul 2016 07:25:52 +0000

Comment # 12 on bug 12645 from 
From bug 12650, closed as a dup:

Stack trace from something more useful than ASAN, when reading the file from
bug 12650 with the tip of the master branch:

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libwireshark.0.dylib              0x000000010e897a14 dissect_mip6 + 5412
(packet-mip6.c:4218)
1   libwireshark.0.dylib              0x000000010e3610db call_dissector_work +
235 (packet.c:648)
2   libwireshark.0.dylib              0x000000010e3605a2
call_dissector_with_data + 50 (packet.c:2793)
3   libwireshark.0.dylib              0x000000010e7c0da3 dissect_ah + 595
(packet-ipsec.c:1156)
4   libwireshark.0.dylib              0x000000010e3610db call_dissector_work +
235 (packet.c:648)
5   libwireshark.0.dylib              0x000000010e360fb5 dissector_try_uint_new
+ 101 (packet.c:1188)
6   libwireshark.0.dylib              0x000000010e7a2240 ip_try_dissect + 128
(packet-ip.c:1976)
7   libwireshark.0.dylib              0x000000010e7a40c7 dissect_ip_v4 + 5479
(packet-ip.c:2439)
8   libwireshark.0.dylib              0x000000010e3610db call_dissector_work +
235 (packet.c:648)
9   libwireshark.0.dylib              0x000000010e3611c3 dissector_try_uint +
99 (packet.c:1188)
10  libwireshark.0.dylib              0x000000010e65dd96 dissect_ethertype +
326 (packet-ethertype.c:262)
11  libwireshark.0.dylib              0x000000010e3610db call_dissector_work +
235 (packet.c:648)
12  libwireshark.0.dylib              0x000000010e3605a2
call_dissector_with_data + 50 (packet.c:2793)
13  libwireshark.0.dylib              0x000000010e65d5d6 dissect_eth_common +
3126 (packet-eth.c:542)
14  libwireshark.0.dylib              0x000000010e65c980 dissect_eth + 256
(packet-eth.c:805)
15  libwireshark.0.dylib              0x000000010e3610db call_dissector_work +
235 (packet.c:648)
16  libwireshark.0.dylib              0x000000010e360fb5 dissector_try_uint_new
+ 101 (packet.c:1188)
17  libwireshark.0.dylib              0x000000010e68c1d8 dissect_frame + 2856
(packet-frame.c:507)
18  libwireshark.0.dylib              0x000000010e3610db call_dissector_work +
235 (packet.c:648)
19  libwireshark.0.dylib              0x000000010e3605a2
call_dissector_with_data + 50 (packet.c:2793)
20  libwireshark.0.dylib              0x000000010e360462 dissect_record + 626
(packet.c:533)
21  libwireshark.0.dylib              0x000000010e3562e4
epan_dissect_run_with_taps + 68 (epan.c:379)
22  tshark                            0x000000010e24cec5 process_packet + 373
(tshark.c:3417)
23  tshark                            0x000000010e24a7cb main + 10923
(tshark.c:3170)
24  libdyld.dylib                     0x00007fff90bfe5ad start + 1

and that's

    iph->ip_nxt = pproto;

so somebody's calling the dissector with a null data pointer.

The call before line 1156 of packet-ipsec.c is:

    call_dissector(dissector_handle, next_tvb, pinfo, tree);

and *that* passes a null pointer as data.

It's handing off the packet to a dissector taken from the IP dissector table;
presumably those dissectors are expecting to be handed a ws_ip *.  Perhaps we
should just pass along iph; if we do, no crash.

Unfortunately, iph isn't necessarily available.

So why exactly must we set the "next header" field here?

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