Discard optimized containers with negative counts in UBJSON/BJData (#3491,#3492,#3490)

[fangq]

This may partially address the fuzzer errors reported in #3491, #3492 and #3490.

Specifically, the above failed fuzzer errors appear to be triggered when an ND-array optimized header contains 0 in any of the dimensional vector elements. This causes partially written objects and array constructs.

Another issue this patch fixes is related to the implementation-spec mismatch discussed in #3492 (comment)

a negative count should result in an invalid UBJSON and BJData input.

[coveralls]

Coverage remained the same at 100.0% when pulling cbf72c6 on NeuroJSON:issue3492 into 6a73920 on nlohmann:develop.

[nlohmann]

I checked the fix with the inputs of issues #3491, #3492, and #3490, and none encountered the assertions I added in #3498. I only have some smaller remarks.

[nlohmann]

Looks good to me.

[nlohmann]

I let the fuzzer run on the now-merged branch and see no issues after letting it run for half an hour. 👍

[nlohmann]

@fangq

I think I found another issue:

In the binary reader in function get_ubsize_size_value, we have

string_t key = "_ArraySize_";
if (JSON_HEDLEY_UNLIKELY(!sax->start_object(3) || !sax->key(key) || !sax->start_array(dim.size())))
{
    return false;
}

In an example input, I get the following SAX events:

<object size="3">
    <key key="_ArraySize_" />
    <array size="2">
        <number_integer val="2148925440" />
        <number_integer val="6701356247676222464" />
    </array>

However, the object that is started with sax->start_object(3) is never ended with a closing end_object() call. This yields issues down the road in the SAX-DOM parser, because, we when we call the return sax->end_array(); line at the end of the code block, we are still inside the unclosed object we started before.

Here is the respective input: crash.bjdata.zip

I will re-run the fuzzer with the enabled assertions from #3498 and see if I can find smaller examples.

[nlohmann]

Here is a 14 byte example:

00000000: 5b5b 235b 5500 5b55 ff69 5d5d 5d5d       [[#[U.[U.i]]]]

which produces these SAX events:

<array>
    <object size="3">
        <key key="_ArraySize_" />
        <array size="2">
            <number_integer val="255" />
            <number_integer val="93" />
        </array>
        <array size="0">
        </array>
    </array>

The more I look at it: why is there a hard-coded 3 for the object size?

minimized.bjdata.zip

[fangq]

@nlohmann, let me know if the patch if #3502 fixes the errors.