[oss-fuzz] ERROR: Adding ospf.v3.prefix.options.nu would put more than 1000000 items in the tree -- possible infinite loop
This issue was migrated from bug 14978 in our old bug tracker.
Original bug information:
Reporter: Peter Wu
Status: RESOLVED FIXED
Product: Wireshark
Component: Dissection engine (libwireshark)
OS: Linux
Platform: x86-64
Version: Git
Attachments:
clusterfuzz-testcase-minimized-fuzzshark_ip_proto-ospf-5128657784799232.pcap: Packet capture file
backtraces-v3.1.0rc0-662-gfd30adca44.txt: Backtraces for the exception and 7 proto items using v3.1.0rc0-662-gfd30adca
Activity
Build Information: TShark (Wireshark) 2.9.0 (v2.9.0rc0-1226-g599ee9f0)
Copyright 1998-2018 Gerald Combs <gerald@wireshark.org> and contributors. License GPLv2+: GNU GPL version 2 or later <http://www.gnu.org/licenses/old-licenses/gpl-2.0.html> This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Compiled (64-bit) with libpcap, with POSIX capabilities (Linux), with libnl 3, with GLib 2.56.0, with zlib 1.2.11, without SMI, with c-ares 1.14.0, with Lua 5.2.4, with GnuTLS 3.5.18, with Gcrypt 1.8.3, with MIT Kerberos, with MaxMind DB resolver, with nghttp2 1.32.0, with LZ4, with Snappy, with libxml2 2.9.8.
Running on Linux 4.17.2-1-ARCH, with Intel(R) Core(TM) i7-6700HQ CPU @ 2.60GHz (with SSE4.2), with 31988 MB of physical memory, with locale C, with libpcap version 1.8.1, with GnuTLS 3.5.18, with Gcrypt 1.8.3, with zlib 1.2.11, binary plugins supported (13 loaded).
Built using clang 4.2.1 Compatible Clang 6.0.0 (tags/RELEASE_600/final).
A problem was found by the oss-fuzz project: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=9367 Attached is the sample that triggers this error which can be reproduced with an ASAN+UBSAN build of Wireshark: tshark -Vxr clusterfuzz-testcase-minimized-fuzzshark_ip_proto-ospf-5128657784799232.pcap -- ** (process:12748): ERROR **: 21:45:15.099: Adding ospf.v3.prefix.options.nu would put more than 1000000 items in the tree -- possible infinite loop AddressSanitizer:DEADLYSIGNAL ================================================================= ==12748==ERROR: AddressSanitizer: ABRT on unknown address 0x03e8000031cc (pc 0x7f986d79c86b bp 0x7fff391129f0 sp 0x7fff39112790 T0) #0 0x7f986d79c86a in __GI_raise (/usr/lib/libc.so.6+0x3686a) #1 0x7f986d78740d in __GI_abort (/usr/lib/libc.so.6+0x2140d) #2 0x7f9887f83694 in abort_handler (libtrapabort.so+0x694) #3 0x7f986df53a7f (/usr/lib/libpthread.so.0+0x11a7f) #4 0x7f986e1b1ed1 in _g_log_abort /build/src/glib/glib/gmessages.c:580 #5 0x7f986e1b2f7c in g_log_default_handler /build/src/glib/glib/gmessages.c:3158 #6 0x5614552f8708 in tshark_log_handler tshark.c:522:3 #7 0x7f986e1b321e in g_logv /build/src/glib/glib/gmessages.c:1370 #8 0x7f986e1b339f in g_log /build/src/glib/glib/gmessages.c:1432 #9 0x7f987c9c5cb1 in proto_tree_add_boolean64 epan/proto.c:4455:2 #10 0x7f987c99bf83 in proto_item_add_bitmask_tree epan/proto.c:10790:4 #11 0x7f987c99a6b7 in proto_tree_add_bitmask_with_flags epan/proto.c:11127:3 #12 0x7f987c999138 in proto_tree_add_bitmask epan/proto.c:11070:9 #13 0x7f987a3f74f8 in dissect_ospf_v3_lsa epan/dissectors/packet-ospf.c:3516:13 #14 0x7f987a3f3249 in dissect_ospf_ls_upd epan/dissectors/packet-ospf.c:1819:22 #15 0x7f987a3f23b3 in dissect_ospf epan/dissectors/packet-ospf.c:1395:9 #16 0x7f987c8641bb in call_dissector_through_handle epan/packet.c:692:9 #17 0x7f987c84e797 in call_dissector_work epan/packet.c:777:9 #18 0x7f987c84d7f5 in dissector_try_uint_new epan/packet.c:1359:8 #19 0x7f98794cf275 in dissect_exported_pdu epan/dissectors/packet-exported_pdu.c:370:17 #20 0x7f987c8641bb in call_dissector_through_handle epan/packet.c:692:9 #21 0x7f987c84e797 in call_dissector_work epan/packet.c:777:9 #22 0x7f987c84d7f5 in dissector_try_uint_new epan/packet.c:1359:8 #23 0x7f98795f59dd in dissect_frame epan/dissectors/packet-frame.c:579:11 #24 0x7f987c8641bb in call_dissector_through_handle epan/packet.c:692:9 #25 0x7f987c84e797 in call_dissector_work epan/packet.c:777:9 #26 0x7f987c85d1a7 in call_dissector_only epan/packet.c:3090:8 #27 0x7f987c846261 in call_dissector_with_data epan/packet.c:3103:8 #28 0x7f987c845599 in dissect_record epan/packet.c:566:3 #29 0x7f987c7f4068 in epan_dissect_run_with_taps epan/epan.c:551:2 #30 0x561455305690 in process_packet_single_pass tshark.c:3547:5 #31 0x5614552feb8b in process_cap_file tshark.c:3378:11 #32 0x5614552f64b0 in main tshark.c:2050:17 #33 0x7f986d78906a in __libc_start_main (/usr/lib/libc.so.6+0x2306a) #34 0x5614551d8059 in _start (run/tshark+0xe5059) AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: ABRT (/usr/lib/libc.so.6+0x3686a) in __GI_raise ==12748==ABORTINGadded crash libwireshark oslinux versiondev labels
-
In order to reproduce this issue, I had to increase the maximum pcap size as the payload is 490 kiB: --- a/wiretap/wtap.h +++ b/wiretap/wtap.h @@ -405,3 +405,3 @@ extern "C" { */ -#define WTAP_MAX_PACKET_SIZE_STANDARD 262144 +#define WTAP_MAX_PACKET_SIZE_STANDARD (1024 * 1024) #define WTAP_MAX_PACKET_SIZE_DBUS (128*1024*1024) To abort tshark after printing the message, set env var: WIRESHARK_ABORT_ON_TOO_MANY_ITEMS=1 -
(In reply to Peter Wu from comment #2) > In order to reproduce this issue, I had to increase the maximum pcap size as > the payload is 490 kiB: It means that limitation to 1024 done by build script: 44 echo -en "[libfuzzer]\nmax_len = 1024\n" > $OUT/${fuzzer_name}.options (https://code.wireshark.org/review/gitweb?p=wireshark.git;a=blob;f=tools/oss-fuzzshark/build.sh;h=c14851c5cbe0ba25fe0013e4d85227675aa85a1d;hb=HEAD#l44) doesn't work. 1) kcc did comment on max_len during initial push of fuzzer code: https://github.com/google/oss-fuzz/pull/532#discussion_r111675176 2) looking on https://github.com/google/oss-fuzz/blob/master/docs/new_project_guide.md#custom-libfuzzer-options-for-clusterfuzz max_len is not recomended: > (...) Use of max_len is not recommended as other fuzzing engines may not support that option. (...) I would suggest to add limitation to oss-fuzzshark, cause as I understand some fuzzer can generate even 1MB of payload. // this is just side note, cause there might be still some infinity loop in ospf. -
I've reproduced it locally, and I give the exact error message in the bug report: Unhandled exception ("Adding _ws.expert.severity would put more than 1000000 items in the tree -- possible infinite loop", group=1, code=6) To reproduce it I used docker, but if I run the "reproduce" command I don't get anything. Instead, by lanching gdb as described here https://github.com/google/oss-fuzz/blob/master/docs/debugging.md#debugging-fuzzers-with-gdb I get the error message. I've added breaks for the following functions in gdb: break except_rethrow break except_throw break except_throwd break except_vthrowf break except_throwf and I get this backtrace #0 except_throw (group=1, code=3, msg=0x0) at /src/wireshark/epan/except.c:279 #1 0x00000000006fb1f3 in tvb_ensure_bytes_exist (tvb=<optimized out>, offset=<optimized out>, length=<optimized out>) at /src/wireshark/epan/tvbuff.c:637 #2 0x00000000006a2304 in proto_tree_add_item_new (tree=0x604000157450, hfinfo=0xa5a53e8 <proto_register_ospf.ospff_info+12008>, tvb=0x61d00010c480, start=501073, length=<optimized out>, encoding=0) at /src/wireshark/epan/proto.c:3370 #3 0x00000000006c6b2a in proto_tree_add_bitmask_with_flags (parent_tree=0x604000157450, tvb=0x61d00010c480, offset=501073, hf_hdr=<optimized out>, ett=31007, fields=0xa5afae0 <bf_v3_prefix_options>, encoding=<optimized out>, flags=<optimized out>) at /src/wireshark/epan/proto.c:11324 #4 0x00000000006c6a19 in proto_tree_add_bitmask (parent_tree=0x1, tvb=0x3, offset=0, hf_hdr=-32, ett=0, fields=0x0, encoding=0) at /src/wireshark/epan/proto.c:11269 #5 0x00000000015858fc in dissect_ospf_v3_lsa (tvb=0x61d00010c480, pinfo=0x614000010058, offset=501072, tree=0x604000157450, disassemble_body=1406032, address_family=6 '\006') at /src/wireshark/epan/dissectors/packet-ospf.c:3678 #6 0x0000000001583391 in dissect_ospf_ls_upd (tvb=0x61d00010c480, pinfo=0x614000010058, offset=20, tree=<optimized out>, version=3 '\003', length=<optimized out>, address_family=<optimized out>) at /src/wireshark/epan/dissectors/packet-ospf.c:1841 #7 0x000000000158218e in dissect_ospf (tvb=<optimized out>, pinfo=0x614000010058, tree=0x619000002000, data=<optimized out>) at /src/wireshark/epan/dissectors/packet-ospf.c:1417 #8 0x0000000000665527 in call_dissector_through_handle (handle=<optimized out>, tvb=0x61d00010c480, pinfo=<optimized out>, tree=0x619000002000, data=0x0) at /src/wireshark/epan/packet.c:706 #9 0x000000000065d6b9 in call_dissector_work (handle=0x6040000f6750, tvb=0x61d00010c480, pinfo_arg=0x614000010058, tree=0x619000002000, add_proto_name=1, data=0x0) at /src/wireshark/epan/packet.c:791 #10 0x00000000006641b2 in call_all_postdissectors (tvb=0x61d00010c480, pinfo=0x614000010058, tree=0x619000002000) at /src/wireshark/epan/packet.c:3516 #11 0x0000000000ea7dd3 in dissect_frame (tvb=<optimized out>, pinfo=<optimized out>, parent_tree=<optimized out>, data=<optimized out>) at /src/wireshark/epan/dissectors/packet-frame.c:703 #12 0x0000000000665527 in call_dissector_through_handle (handle=<optimized out>, tvb=0x61d00010c480, pinfo=<optimized out>, tree=0x619000002000, data=0x7fffffffdb20) at /src/wireshark/epan/packet.c:706 #13 0x000000000065d6b9 in call_dissector_work (handle=0x604000060490, tvb=0x61d00010c480, pinfo_arg=0x614000010058, tree=0x619000002000, add_proto_name=1, data=0x7fffffffdb20) at /src/wireshark/epan/packet.c:791 #14 0x000000000065ac3a in call_dissector_with_data (handle=0x1, tvb=0x61d00010c480, pinfo=0x614000010058, tree=0x619000002000, data=0x0) at /src/wireshark/epan/packet.c:3154 #15 0x000000000065a42f in dissect_record (edt=0x614000010040, file_type_subtype=<optimized out>, rec=0x7ffff7f4d220, tvb=0x61d00010c480, fd=<optimized out>, cinfo=<optimized out>) at /src/wireshark/epan/packet.c:580 #16 0x000000000064e754 in epan_dissect_run (edt=0x614000010040, file_type_subtype=0, rec=0x7ffff7f4d220, tvb=0x61d00010c480, fd=0x7ffff7f4d370, cinfo=0x0) at /src/wireshark/epan/epan.c:550 #17 0x000000000053815e in LLVMFuzzerTestOneInput (buf=<optimized out>, real_len=501073) at /src/wireshark/fuzz/fuzzshark.c:343 #18 0x000000000258b167 in ExecuteCallback () at /src/libfuzzer/FuzzerLoop.cpp:529 #19 0x000000000254b537 in RunOneTest () at /src/libfuzzer/FuzzerDriver.cpp:286 #20 0x0000000002557064 in FuzzerDriver () at /src/libfuzzer/FuzzerDriver.cpp:715 #21 0x000000000254abad in main () at /src/libfuzzer/FuzzerMain.cpp:19 That leads me to packet-frame.c:703. -
Change 33060 had a related patch set uploaded by Dario Lombardo: frame: increase EXCEPTION_TREE_ITEMS by 2.
-
Created attachment 17106 Backtraces for the exception and 7 proto items using v3.1.0rc0-662-gfd30adca44 I am still able to reproduce this issue with master v3.1.0rc0-662-gfd30adca44 and the reproducer from the oss-fuzz issue tracker: HOME=/x FUZZSHARK_TABLE=ip.proto FUZZSHARK_TARGET=ospf fuzzshark clusterfuzz-testcase-minimized-fuzzshark_ip_proto-ospf-5128657784799232 Attached are the traces for watchpoints on changes to parent_tree.tree_data.count, this revealed 7 nodes that were added from the catch block in epan/expert.c:759 show_reported_bounds_error adds a proto node and calls expert_add_info: 1. _ws.malformed - protocol node via epan/show_exception.c:177 expert_create_tree adds two items: 2. _ws.malformed - expert tree via epan/expert.c:480 3. _ws.malformed - protocol filter because group==PI_MALFORMED via epan/expert.c:488 Because an explicit ei field was given: "add_expert_info(..., &ei_malformed)", two fields are added instead of one: 4. _ws.malformed.expert - none node via epan/expert.c:543 5. _ws.expert.message - string node via epan/expert.c:545 Two more fields are added for the severity and group: 6. _ws.expert.severity - uint node via epan/expert.c:549 7. _ws.expert.group - uint node via epan/expert.c:552 So this problem would never occur when an exception is triggered via DISSECTOR_ASSERT, but only for ReportedBoundsError exceptions (which occur when trying to use proto_tree_add_item with invalid bounds for a tvb). -
Change 33060 merged by Dario Lombardo: frame: increase EXCEPTION_TREE_ITEMS.
-
Change 33122 had a related patch set uploaded by Peter Wu: frame: increase EXCEPTION_TREE_ITEMS.
-
Change 33122 merged by Peter Wu: frame: increase EXCEPTION_TREE_ITEMS.
-
Change 33123 had a related patch set uploaded by Peter Wu: frame: increase EXCEPTION_TREE_ITEMS.
-
Change 33123 merged by Peter Wu: frame: increase EXCEPTION_TREE_ITEMS.
Please register or sign in to reply