cbor_value_enter_container and advance_internal are not assert-safe.

[jmccullough0]

cbor_value_enter_container and advance_internal assert-fail when they fail to extract a number from the input data. Returning an error code instead would allow for more graceful error handling when dealing with untrusted data.

[thiagomacieira]

You're referring to this part of advance_internal:

    uint64_t length;
    CborError err = extract_number(&it->ptr, it->parser->end, &length);
    assert(err == CborNoError);

In order for that assertion to fail, you must have got an error code already from the previous CborValue advancing.(from preparse_value). If you managed to get a valid CborValue with no error code in a condition that advance_internal will assert, please post the code.

[thiagomacieira]

cbor_value_enter_container has this assertion:

    assert(cbor_value_is_container(it));

Many other TinyCBOR functions assert that the type of the incoming CborValue is the one expected in the function name. For example, in cbor.h:

CBOR_INLINE_API CborError cbor_value_get_boolean(const CborValue *value, bool *result)
{
    assert(cbor_value_is_boolean(value));
    *result = value->extra;
    return CborNoError;
}

I will not change that.

It has this other assertion:

        uint64_t len;
        err = extract_number(&recursed->ptr, recursed->parser->end, &len);
        assert(err == CborNoError);

The answer here is the same as for advance_internal: you may not ignore an error and call another function in the library.

Let me know if you didn't ignore an error.

[jmccullough0]

Found a missing error check on a cbor_parser_init call, thanks for your attention!