stack overflow while fuzzing parse-cbor-fuzzer

[3iang]

Description

poc.json

(venv) [AFL++ 5e685e9c5417] /src/json # cat ./dup-co-2-7qye3d1b/jsoncxx2/crashes/id:000000,sig:11,src:002057,time:815305,execs:11664684,op:havoc,rep:12 | ./json-3.11.3/tests/parse_cbor_fuzzer clear
AddressSanitizer:DEADLYSIGNAL
=================================================================
==66107==ERROR: AddressSanitizer: stack-overflow on address 0x7ffd3b5277f8 (pc 0x563deef9c22a bp 0x7ffd3b528020 sp 0x7ffd3b5277f0 T0)
    #0 0x563deef9c22a in operator new(unsigned long) (/src/json/json-3.11.3/tests/parse_cbor_fuzzer+0xe322a) (BuildId: ec0a1fe618cefe6fec0b3f9581932abdb6706b8b)
    #1 0x563deefb2d07 in __gnu_cxx::new_allocator<nlohmann::json_abi_v3_11_3::basic_json<std::map, std::vector, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, bool, long, unsigned long, double, std::allocator, nlohmann::json_abi_v3_11_3::adl_serializer, std::vector<unsigned char, std::allocator<unsigned char> >, void> >::allocate(unsigned long, void const*) /usr/lib/gcc/x86_64-linux-gnu/11/../../../../include/c++/11/ext/new_allocator.h:127:27
    #2 0x563deefb2d07 in std::allocator_traits<std::allocator<nlohmann::json_abi_v3_11_3::basic_json<std::map, std::vector, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, bool, long, unsigned long, double, std::allocator, nlohmann::json_abi_v3_11_3::adl_serializer, std::vector<unsigned char, std::allocator<unsigned char> >, void> > >::allocate(std::allocator<nlohmann::json_abi_v3_11_3::basic_json<std::map, std::vector, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, bool, long, unsigned long, double, std::allocator, nlohmann::json_abi_v3_11_3::adl_serializer, std::vector<unsigned char, std::allocator<unsigned char> >, void> >&, unsigned long) /usr/lib/gcc/x86_64-linux-gnu/11/../../../../include/c++/11/bits/alloc_traits.h:464:20
    #3 0x563deefb2d07 in std::_Vector_base<nlohmann::json_abi_v3_11_3::basic_json<std::map, std::vector, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, bool, long, unsigned long, double, std::allocator, nlohmann::json_abi_v3_11_3::adl_serializer, std::vector<unsigned char, std::allocator<unsigned char> >, void>, std::allocator<nlohmann::json_abi_v3_11_3::basic_json<std::map, std::vector, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, bool, long, unsigned long, double, std::allocator, nlohmann::json_abi_v3_11_3::adl_serializer, std::vector<unsigned char, std::allocator<unsigned char> >, void> > >::_M_allocate(unsigned long) /usr/lib/gcc/x86_64-linux-gnu/11/../../../../include/c++/11/bits/stl_vector.h:346:20
...

Reproduction steps

cat poc.json | ./parse_cbor_fuzzer

Expected vs. actual results

Expected no stack overflow.

Minimal code example

No response

Error messages

No response

Compiler and operating system

afl-clang-fast++

Library version

3.11.3

Validation

• The bug also occurs if the latest version from the develop branch is used.
• I can successfully compile and run the unit tests.

[nlohmann]

Do you have a stack trace for the input? I would expect it to be a nested array - the CBOR equivalent to

[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[...]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]

I've seen these inputs being generated by OSSFuzz, and there is currently little we can do.

[3iang]

I think you are right and the full stacktrace is similar as this :
bt.txt

[t-b]

I've seen these inputs being generated by OSSFuzz, and there is currently little we can do.

Could you elaborate? I would prefer not having a possible stack-overflow here.

[github-actions]

This issue has been marked as stale because it has been open for 90 days without activity. If this issue is still relevant, please add a comment or remove the "stale" label. Otherwise, it will be closed in 10 days. Thank you for helping us prioritize our work!

[t-b]

bump

[nlohmann]

Could you elaborate? I would prefer not having a possible stack-overflow here.

The parser is implemented using recursive descent, and inputs that are nested too deeply result in a stack overflow. The example has 245 nested arrays and a stack trace of depth 492.

I would prefer not having a possible stack-overflow here.

Yes, of course. What would be the alternatives? I can think of:

• Artificially limit the depth of nesting.
• Rewrite the parser.